kamkasravi at yahoo.com
Wed Nov 2 13:39:27 PDT 2011
On Nov 2, 2011, at 1:20 PM, Brendan Eich <brendan at mozilla.com> wrote:
> On Nov 2, 2011, at 1:17 PM, Kam Kasravi wrote:
>> On Nov 2, 2011, at 11:29 AM, Brendan Eich <brendan at mozilla.com> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss