> > I thought the idea of max/min classes was to stay as true to the OOP > patterns used today as possible? So shouldn't the question be reversed and > classes should work like sugar for functions intended for use as > constructors instead of breaking that model and requiring justification in > a later draft to restore expected behavior? >
This was where we started out. But it was found that the "just sugar" design was incompatible with the design goal of allowing subclassing of built-ins. It's an inescapable dilemma: JavaScript has two simultaneous models for "classes": the builtin model, in which objects are "birthed" with a certain internal shape, and the function-constructor model, in which objects are birthed as undifferentiated plain objects and it is up to constructors to give them shape. In order to allow subclassing as built-ins, we had to opt for the builtin model. This is actually a good thing, because it paves the way for user-defined classes with per-instance (private) internal shape.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
