Operator overloading revisited
alex at dojotoolkit.org
Wed Jul 22 07:39:35 PDT 2009
-----BEGIN PGP SIGNED MESSAGE-----
On Jul 22, 2009, at 3:10 AM, Christian Plesner Hansen wrote:
>> The current class proposal,
>> 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/
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.
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)
-----END PGP SIGNATURE-----
More information about the es-discuss