Skip to content
This repository has been archived by the owner on Jan 25, 2022. It is now read-only.

Update FAQ regarding the sigil #84

Open
jamesplease opened this issue Jun 6, 2017 · 3 comments
Open

Update FAQ regarding the sigil #84

jamesplease opened this issue Jun 6, 2017 · 3 comments

Comments

@jamesplease
Copy link

jamesplease commented Jun 6, 2017

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
Copy link
Contributor

bakkot commented Jun 6, 2017

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
Copy link
Contributor

bakkot commented Jun 6, 2017

(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
Copy link
Member

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants