Hello Mark, I think mistake is a harsh word. It is really a question of how much the community wants javascript to adopt object-oriented paradigms. You could go all the way and make classes a very strict subset of the language: throw an error if the user tries to set a property of a class instance that has already been declared private. Or, on the complete opposite side of the spectrum: setting the property on an instance overwrite it, just like it would if the class instance was a normal object.
I would personally prefer the prior route: sacrifice some of javascript's dynamic attributes in favor of better abstraction and encapsulation capabilities. Of course, we're only talking about class instances here, so I think that's a very small sacrifice to be made. Perhaps you could direct me to the discussion the committee has already had on this matter so I could better form my arguments? Jonathan Dumaine +1 50.55.10.11.12 On Sat, Sep 17, 2011 at 3:37 PM, Mark S. Miller <erig...@google.com> wrote: > Hi Jonathan, > > Your class recapitulates a mistake the committee almost made as well. Your > private and public member are in the same namespace. Private members should > not affect the behavior of the public API. However, if a class makes an > extensible instance, and a client of the instance tries to add an "_x" > expando property to that instance, where that happens to conflict with one > of that abstraction's private names, what should happen? > > -- > Cheers, > --MarkM > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
