On Jun 8, 2011, at 3:05 AM, Brendan Eich <bren...@mozilla.com> wrote:

> On Jun 8, 2011, at 2:45 AM, Kam Kasravi wrote:
> 
>> Just as the private(this) is used to expose the private instance record,
> 
> Please read 
> 
> private(this), e.g., is
> unbearably verbose;
> leaks an implementation detail.
> from http://wiki.ecmascript.org/doku.php?id=harmony:classes#open_issues.
> 
> The syntax is a placeholder. It will not last.
> 
> 
>> could static([[Constructor]]) be introduced to provide access to the union 
>> of static properties across the set of constructor objects? (I know that 
>> their is some concern about the lengthy syntax of private())
> 
> It's not "concern", it is an open issue to resolve by using better syntax.
> 
> What does "union of static properties across the set of constructor objects" 
> mean? We're not reifying sets of properties as objects, if that's what you 
> mean (static private yikes).

This was related to Peter's concern included below for brevity

>>> Based on my understanding of what the desugared code would be, the
>>> last line above would be an error because Dragon.allMonsters is
>>> undefined.

I was wondering if this could be solved in some way without explicitly 
referencing the particular Constructor. This isn't a static private issue per 
se, rather a suggestion for an operator that would allow one to reference 
Monster.allMonsters as Dragon.allMonsters. eg static(Dragon).allMonsters. 
Although it would probably be more consistent to resolve Dragon.allMonsters in 
the same way properties on the prototype chain are resolved. So we can probably 
ignore this suggestion.

> 
> I can see how private(foo) brings this to mind. This is the problem I 
> clumsily labeled "leaks an implementation detail".
> 
> 
>> Regarding the use of private(AssignmentExpression), does it provide access 
>> to all private ExportableDefinition's regardless of what inherited class 
>> they were declared in? That is given
>> class Monster { 
>>   constructor(health) { 
>>     private health = health; 
>>   }
>> } 
>> 
>> class GilaMonster prototype Monster {
>>   constructor(owner) { 
>>     super(10); 
>>     private owner = owner;
>>   }
>>   eat(critter) { 
>>     If(critter === private(this).owner) {
>>       private(this).health = 0; 
>>     } else {
>>       private(this).health++;
>>     }
>>   }
>> }
>> 
>> Should the GilaMonster's private record include health?
> 
> The "private record" especially views as an "object" is a kind of placeholder 
> too. It doesn't help to think of it as a record. It probably does not help to 
> think of it as an object, either, especially if you cannot get at it via 
> anything like the still-straw private(this) or private(other) syntax.

Yes, I agree, I was attempting to keep as close as possible to http terminology 
used in the proposal.

> 
> On another topic, it does seem like "protected" is inevitable, doesn't it?

Which may be a slippery slope :( BTW is it premature to ask questions on 
harmony proposals in their current state? 

> 
> /be
> 
>> 
>> 
>> On Jun 6, 2011, at 11:08 AM, Allen Wirfs-Brock <al...@wirfs-brock.com> wrote:
>> 
>>> 
>>> On Jun 6, 2011, at 10:32 AM, Brendan Eich wrote:
>>> 
>>>> On Jun 6, 2011, at 10:19 AM, Bob Nystrom wrote:
>>>> 
>>>>> On Sun, Jun 5, 2011 at 9:35 PM, Peter Michaux <petermich...@gmail.com> 
>>>>> wrote:
>>>>> Based on my understanding of what the desugared code would be, the
>>>>> last line above would be an error because Dragon.allMonsters is
>>>>> undefined.
>>>>> 
>>>>> That's correct. Do you have any examples of code where inheriting the 
>>>>> constructor objects would be helpful?
>>>> 
>>>> Used all the time in Ruby, and in some Smalltalks. Supported by 
>>>> CoffeeScript. See
>>> 
>>> Actually, all modern Smalltalks where modern means anything post 1980
>>> 
>>> 
>>> 
>>> 
>>>> 
>>>> https://gist.github.com/1007150
>>>> https://gist.github.com/1006999
>>>> 
>>>> (warning: Ruby reading skills required).
>>>> 
>>>> /be
>>>> 
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss@mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>> 
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
> 
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to