Proposal to avoid the sigil

[dead-claudia]

I know this is a bit late in the game, but while typing out a reply to an es-discuss email, I just realized how you could avoid the sigil on property access, only requiring a sigil or keyword when declaring the field:

1. If you're accessing a computed property, get it as normal.
2. If you're in eval code and not in a class defined in it, get it as normal.
3. If you're accessing the property outside a class, or if the property being accessed doesn't share a name with the private field, get it as normal.
4. If the property is a private static property, and the value is not the enclosing class, throw an error.
5. If the property is a private instance property, and the value was not created using the enclosing class's constructor, throw an error.
6. Finally, failing all this, get the private property slot.

I know that's a bit complex in terms of logic, but parsers already have to do that anyways to correctly parse private field accesses with a sigil, so the difference is mostly superficial:

• Private fields with a sigil can't be computed. You are already bailing out early.
• Private fields with a sigil can't be accessed in eval code when the class isn't defined in it. You are already bailing out early.
• Private fields with a sigil can't be used outside a class, nor can they be used when no such symbol exists. You are already bailing out early.
• You already have to check the type of the value when doing syntactic checks, since invalid targets when reading private fields are runtime errors.

As for runtime perf impact, you can do the same analysis as you did previously. The only difference is that engines would defer the analysis to bytecode generation time rather than initial parsing (which would speed that part up a little).

[dead-claudia]

Note: I'm not too invested in this, and I actually kind of prefer the sigil (typing this. over and over gets annoying after a while). I was just driven by others' aesthetic interest, and wanted to prove it wasn't not viable.

[bakkot]

This has come up before and is what this question in the FAQ is intended to respond to.

[dead-claudia]

@bakkot I'm aware, and it's why I explicitly noted that computed property access is exempt, and it's why I made the rule apply to all property accesses, not just those of a certain type. It would make it much more obvious that you need to fix your code.

Also, just to reinforce my opinions on this, I actually see more drawbacks than plusses for this, and I'm not sure the subjective elegance is offset by the potential for confusion. (I've already been bitten a few too many times with Ruby doing similar with variable lookup.) My objective was to show it wasn't something impossible or incredibly awkward to spec, as a proof of concept, not to actually push for it. (I created this and linked to it in the relevant email to give others an ability to vouch for it themselves.)

[bakkot]

@isiahmeadows The FAQ entry I linked doesn't say anything about computed vs static; I don't understand why it matters. I'm not sure how your suggestion is intended to avoid this problem:

Class methods often manipulate objects which are not instances of the class. It would be surprising if the code obj.x suddenly stopped referring to public field x of obj, when obj is not expected to be an instance of the class, just because that code happened to occur somewhere within a class which declares a private field named x, possibly deep within said class.

That's my main objection to it. It's not that it's impossible or awkward to spec, just that I think it has bad semantics.

[doodadjs]

@bakkot "This is only an issue in JavaScript because of its lack of static types."

Please see Optional Static Typing Proposal

[bakkot]

@doodadjs adding types is far beyond the scope of this proposal.

[rdking]

I have another idea for avoiding the sigil here that would affect this proposal, the proposal for private methods, and make adding protected members in the future significantly easier, all without introducing anything that breaks the desired effects mentioned by the FAQ for this proposal.

[glen-84]

@bakkot Would optional static typing enable sigilless private fields?

(apologies if I've asked this before, my memory is terrible)

Edit: Ah, you sort of answered that here.

With the above optional static typing proposal, I really think that my suggestion should be given some more thought before it's "too late". It would satisfy both groups.

...

class Example {
    ##hidden1 = "really hidden";
    ##hidden2 = "no, really";

    private x = "private";
    private y = "clean syntax";
    private z = "implement when technically possible";
}

[littledan]

Thanks for the explanations, @bakkot.

@glen-84 I'd be worried that adding multiple types of private would be a bit confusing for programmers. I think we should start off with just one kind of private.