On Sun, Sep 18, 2011 at 1:36 AM, Jonathan Dumaine <jonathan.duma...@dumstruck.com> wrote: > 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 [...] > I would personally prefer the prior route: sacrifice some of javascript's > dynamic attributes in favor of better abstraction and encapsulation > capabilities.
But one problem here is exactly related to abstraction and encapsulation: the class's implementation can't add a new private property without risking breaking of existing clients: if they were using the newly-claimed name as an "expando" property's name, then the changes to the "encapsulated and abstracted" internal representation will cause them to error out. Mike _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss