On Nov 2, 2011, at 1:20 PM, Brendan Eich <[email protected]> wrote:
> On Nov 2, 2011, at 1:17 PM, Kam Kasravi wrote: > >> On Nov 2, 2011, at 11:29 AM, Brendan Eich <[email protected]> wrote: >> >>> On Nov 2, 2011, at 11:17 AM, David Bruant wrote: >>> >>>>> See my reply to Kam. We're not sugaring instance-private ivars. I am >>>>> proposing something we agreed to in Nov. 2008: sugaring class-private >>>>> ivars. >>>> Ok, that's what I was missing. What were the rationale? use cases? >>> >> Doesn't the latest harmony class proposal define private within the >> constructor? I assume this proposal would supersede the Nov 2008 meeting >> Grammar pasted below: > > Are you asking a procedural question, or something? If so, bzzzt. :-| > > I'm hacking a gist forked from Jeremy's. But TC39 is sticking to consensus > where we can. The wiki'ed class proposal does have class-private instance > variables. It simply mislocates the private declaration inside the > constructor. Again, this proposal is in trouble and the gist'ing is an > attempt to rescue it, outside the confines of the somewhat-overconstrained > TC39 setting. > Understood, just wanted to clarify exactly what the TC39 consensus was in respect to the harmony class proposal. I do think your gist has advantages over the harmony class proposal both in terms of removing the public keyword and clarifying private-class var declaration and semantics. My only concern would be users/framework writers opting for the closure pattern in lieu of using private to prevent the Account use case I noted. That is, I would normally interpret private to mean no access unless you're the instance and within class scope. Here private means no access unless you're any instance and within class scope. > /be >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
