Operator overloading revisited

[Alex Russell]

-----BEGIN PGP SIGNED MESSAGE-----
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.

Regards

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)

iD8DBQFKZySoz3jiQlnDlyMRAjpeAJ9R0PkZOTVx7dtV05qzF2X0sisbRACgm3ta
exbKWvCTD1Y8ZkR4BZMQu8U=
=TLUq
-----END PGP SIGNATURE-----