Operator overloading revisited
Mark S. Miller
erights at google.com
Wed Jul 22 07:52:23 PDT 2009
On Wed, Jul 22, 2009 at 3:10 AM, Christian Plesner
Hansen<christian.plesner.hansen at gmail.com> 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?
I have been taking the thread starting at
together with its references to relevant earlier threads as the
strawman of interest. Several people have encouraged me to update the
wiki. My apologies for not having done so.
The proposal in that latest thread itself does not support
inheritance, which seems consistent with the general sense of the
committee. However, if we do decide to support inheritance, the
earlier thread at
shows how to support single inheritance and linearized multiple
inheritance in the same framework.
Alex mentions traits. Traits seem like a more structured form of
behavior sharing than classical inheritance. Lately Alex and I been
Later today I will post some initial thoughts on how this could also
be supported in within the same general framework.
The design of well structured inheritance-like behavior sharing
machinery is far from settled. As with data types, the ideal outcome
would be for ES6 itself to support well all of these as patterns
without building any of them in, so that our users and library authors
can try multiple experiments.
More information about the es-discuss