Harmony:classes static and private

Kam Kasravi kamkasravi at yahoo.com
Wed Jun 8 14:11:54 PDT 2011


Hmmm... I'm referencing http://wiki.ecmascript.org/doku.php?id=harmony:classes.
Is this one incorrect?

On Jun 8, 2011, at 11:13 AM, Bob Nystrom <rnystrom at google.com> wrote:

> Either I'm out-of-date or the wiki page is. My understanding is that at the TC39 meetings we decided to move instance and private record declarations out of the class body and into the constructor. If that's the case, this should be less confusing. You can no longer use "public" or "private" at the class body level. So that example becomes:
> 
> class Monster {
>   // "static" places the property on the constructor.
>   static allMonsters = [];
> 
>   // No modifier declares on the prototype.
>   numAttacks = 0;
> 
>   constructor() {
>     // "private" places it on the private record of the new instance.
>     private health;
>   }
> }
> 
> That's better, but "public" and "private" are still less than ideal keywords here since Javascript's use of them is distinctly different from other languages. Alas, they were the best we could come up with.
> 
> As far as your original question, Mark is right. You can have private "static" state by just having a variable in the closure that surrounds the class declaration but that isn't otherwise visible. Modules are one way to do that. This is another:
> 
> var Monster;
> {
>   let allMonsters = [];
>   Monster = class {
>     // can access allMonsters here...
>   }
> }
> 
> (Hopefully I have that right.)
> 
> - bob
> 
> On Wed, Jun 8, 2011 at 1:11 AM, Kam Kasravi <kamkasravi at yahoo.com> wrote:
> Thanks Allen, more than I was hoping for ... 
> 
> 
> On Jun 7, 2011, at 10:11 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> 
>> There are lots of sources about this
>> 
>> The classic but somewhat technical paper that coined the phrase that I misquoted is William Cook's:  http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.102.8635&rep=rep1&type=pdf 
>>  some overviews http://c2.com/cgi/wiki?SubTypingAndSubClassing 
>>   another good overview, from more of a java perspectivehttp://www.mit.edu/~6.170/lectures/lect09-subtyping-handouts.pdf 
>> 
>> Basically, subtyping typically is taken to imply strict substitutability.  An instance of a subtype can be used anywhere an instance of its supertype is expected.   This isn't just about what public methods are available (a subtype have can only add to the supertypes interface).  It is also about what can be passed to and returned form each method, recursively applied.  It is trivial to break such substitutability with JavaScript objects, even those created by the proposed class declarations.  It is possible to create JavaScript objects that behave as subtypes but it takes work.  It may not always be worth the effort.
>> 
>> Statically typed languages and their users are often very concerned about correct subtyping because the memory safety of such languages often depends upon the fact that subtype substitutability invariants are guaranteed.  Dynamic language folks are often less concerned because any such broken invariants will at worst cause the program to perform the wrong computation but dynamic runtime checks will still guarantee memory safety.  Your actual milage may vary. 
>> 
>> Allen
>> (I am not a type theorists)
>> 
>> 
>> 
>> On Jun 7, 2011, at 8:17 PM, Kam Kasravi wrote:
>> 
>>> Yes I puzzled over that a bit :)
>>> 
>>> I realize that types within a typed language need to provide certain guarantees in terms of schema, equivalence, etc. For the those of us more 'untyped' than others, could you expound very briefly on the type vs class distinction? Is it due to javascript's ability to morph a class definition both in terms of its properties and its prototype chain? I also ask due to Dave's suggestion in relation to modules that ES.next is much more amenable to static analysis (paraphrasing) which I would think an IDE would exploit to provide some level of type-checking. In Allen's mirrors article, it seems like types would be important to reflection.
>>> Although wouldn't you know, I searched Allen's article (http://www.wirfs-brock.com/allen/posts/228) and he never once mentions 'type' :)
>>> 
>>> On Jun 7, 2011, at 6:47 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>>> 
>>>> Oops, obviously I meant: JavaScript subclassing is definitely not equivalent to subtyping.  
>>>> 
>>>> Time for dinner-at keyboard too long.
>>>> 
>>>> On Jun 7, 2011, at 6:34 PM, Mark S. Miller wrote:
>>>> 
>>>>> On Tue, Jun 7, 2011 at 6:11 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>>>>> 
>>>>>  In a language as dynamic as JavaScript subtyping is definitely not equivalent to subtyping.
>>>>> 
>>>>> 
>>>>> Wow, JavaScript is even more dynamic than I thought ;). 
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>>     Cheers,
>>>>>     --MarkM
>>>> 
>> 
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110608/1d35140f/attachment-0001.html>


More information about the es-discuss mailing list