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