Operator overloading revisited

Alex Russell alex at dojotoolkit.org
Wed Jul 22 07:39:35 PDT 2009

Hash: SHA1

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?

Lots of babies have already been thrown out in this proposal  
(euphemistically named "Resolved Design Choices"):

   * private by default favors "high integrity" uses of the language,  
punishing the common case and current practice
   * closed-classes ignore both the lessons of Ruby and the way that  
prototypes are currently extended in, say, JQuery
   * the word "prototype" doesn't occur in the proposal anywhere,  
meaning that it's silent on the one existing and useful form of object/ 
factory-function delegation.

My sense of it is that this proposal is driven by a desire to avoid  
hierarchy-as-composition problems (hositing of methods to high  
positions in hierarchies, etc.) -- which is a well-founded fear.  
However, it avoids it not by adding a composition mechanism like  
traits, but instead seeks to turn classes into factories of objects  
that can't be augmented to fix the errors of initial designs, can't be  
easily composed to form new types, and don't fit well with how current  
JS programmers think about their language.

In short, it helps Harmony classes make all of the same mistakes that  
DOM host objects currently plague developers with.


- --
Alex Russell
slightlyoff at google.com
alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723

Version: GnuPG v1.4.2 (Darwin)


More information about the es-discuss mailing list