search

tc39 / proposal-private-fields

A Private Fields Proposal for ECMAScript
https://tc39.github.io/proposal-private-fields/
317 stars 19 forks source link

Update FAQ regarding the sigil #84

Open jamesplease opened 7 years ago

jamesplease commented 7 years ago

The FAQ for the sigil justification links to one comment in this giant issue, but there are seemingly-reasonable resolutions to the problem. @zenparsing , the author of that comment, writes out one good solution here, then says:

I believe this idea was considered early on and rejected, although the rationale probably isn't captured anywhere.

I don't want to start a conversation about whether we need a sigil or not here. But what I would like to see is an update to the README that explains clearly why the sigil is necessary.

Given that the issue has grown to be a million comments long, I think it'd be worthwhile to have a succinct, strong argument for the sigil, and possibly even issues with some of the most popular alternatives. Right now, I'm not convinced that we need the sigil, but the thing is, I'm not as smart as the developers else who are planning this feature, and I'd love to understand why no sigil causes problems.

One way to find "the most popular alternatives" would be to just go through #14 and find all of the posts that have lots of up thumbs.

p.s. let's not argue for or against the sigil here. Keep that over in #14! I just want to see the FAQ updated.

bakkot commented 7 years ago

The FAQ is ultimately mostly about why the sigil is necessary. For example, that particular proposal runs into the issue described here.

What particular question do you want to see the FAQ address which it does not? Is it just "why is the sigil necessary"? The answer to that is "there is no good way to make the proposal work without the sigil"; the justification for why there's no good way is pretty much the entire FAQ.

bakkot commented 7 years ago

(Incidentally, private fields have advanced to stage 3 (EDIT: no they haven't; forgive me. but the remainder is still true.) as part of the combined class fields proposal, and unlikely to change. As such, here's no longer much point in discussing whether the sigil is necessary; the committee has resolved that question to its satisfaction. Certainly we have some work to do explaining why it's necessary to a broader audience.)

littledan commented 7 years ago

I'm not the biggest fan of the FAQ's phrasing that there's this one killer argument for why we need the sigil. There are actually a whole bunch of smaller reasons that push us in that direction; maybe it'd be good to have an expanded explainer for this.

I wonder if, in our explanation to users, we can move away from "why not this" and more, "what's the intuition for the current proposal". For me, the intuition is, # is the new _: Name your fields (and hopefully soon, methods and accessors) starting with # if you want them to be accessible only within the class body. Since it's part of the name, you need to write it both on definition and usage.