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 <[email protected]> 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 <[email protected]> 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 < <[email protected]> > [email protected]> wrote: > >> Thanks Allen, more than I was hoping for ... >> >> >> On Jun 7, 2011, at 10:11 PM, Allen Wirfs-Brock < <[email protected]> >> [email protected]> 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 < >> <[email protected]><[email protected]> >> [email protected]> 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 >> <<[email protected]><[email protected]><[email protected]> >> [email protected]> 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 >> <[email protected]>[email protected] >> <https://mail.mozilla.org/listinfo/es-discuss> >> https://mail.mozilla.org/listinfo/es-discuss >> >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
