Operator overloading revisited
mikewse at hotmail.com
Wed Jul 22 16:29:36 PDT 2009
[Still staying in this thread although bad match to subject line, as
I'd like to continue on the discussion of open vs closed classes]
Brendan Eich wrote:
> On Jul 22, 2009, at 3:10 AM, Christian Plesner Hansen wrote:
> >> The current class proposal,
> >> http://wiki.ecmascript.org/doku.php?id=strawman:classes
> >> has zero inheritance.
> > I was under the impression that the plan was to develop some form of
> > inheritance model too. The strawman says that there is no
> > to keep the design simple. Are you sure you're not
> throwing the baby
> > out with the bathwater here?
> Nothing is thrown out by starting simple and then considering our
I agree a lot with Alex about wanting the ability to create non-
frozen classes with the new class mechanism (with respect for
not having the whole picture as you in the committee have).
Once the new class mechanism was deployed I was hoping to be able
to use it for any class-oriented problem, and not having to fall
back on old-style prototypes/constructors for certain kinds of
With the current (small) feature list of classes I guess it's hard
to provide any hard arguments against keeping old-style
constructors for open classes, and it *is* elegant to keep the
purpose of existing language mechanisms.
Though, to me it looks like there is a risk that this design will
not fit so well when later expanding the feature list with f ex
inheritance or class introspection, and that will leave open
classes in the back-water and developers facing questions like:
- Ah, you want to use the new non-clunky inheritance mechanism
that doesn't force you to actually set up the inheritance through
a constructor call to the superclass?
Sorry, only available in frozen classes.
- Or, you want the new inheritance mechanism that chains constructor
calls at instance creation? Only available in frozen classes.
- Or, you want to introspect the class to see what members instances
will get, without creating and introspecting an actual instance?
Only in frozen classes.
Of course I am only speculating about potential future additions
here, but it is easy to fear that the old-style constructors will
have a hard time keeping up with a class mechanism that actually
has a class declaration to build features upon.
More information about the es-discuss