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

Reply via email to