Operator overloading revisited

[Mike Wilson]

[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 
> inheritance
> > 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  
> options.

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
classes.

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.

Best regards
Mike