Harmony:classes static and private

Bob Nystrom rnystrom at google.com
Wed Jun 8 14:32:03 PDT 2011


You're referencing the correct one, but the committee met recently and
changes discussed there may not have made it to the wiki yet.

- bob

On Wed, Jun 8, 2011 at 2:11 PM, Kam Kasravi <kamkasravi at yahoo.com> wrote:

> 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>
> 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>
>> 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><http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.102.8635&rep=rep1&type=pdf>
>> 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><http://c2.com/cgi/wiki?SubTypingAndSubClassing>
>> 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><http://www.wirfs-brock.com/allen/posts/228>
>> 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><allen at wirfs-brock.com>
>> 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><allen at wirfs-brock.com><allen at wirfs-brock.com>
>> 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>es-discuss at mozilla.org
>>  <https://mail.mozilla.org/listinfo/es-discuss>
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110608/00e899bd/attachment.html>


More information about the es-discuss mailing list