Harmony:classes static and private

Bob Nystrom rnystrom at google.com
Wed Jun 8 11:13:11 PDT 2011

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=>
> http://citeseerx.ist.psu.edu/viewdoc/download?doi=
>  some overviews  <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) 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> 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> 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/690aab37/attachment-0001.html>

More information about the es-discuss mailing list