Classes as Sugar is now ready for discussion

Dirk Pranke dpranke at chromium.org
Wed Sep 8 12:42:00 PDT 2010


On Wed, Sep 8, 2010 at 10:16 AM, P T Withington <ptw at pobox.com> wrote:
> On 2010-09-05, at 10:33, Mark S. Miller wrote:
>
>> http://wiki.ecmascript.org/doku.php?id=strawman:classes_as_sugar
>>
>> Of the three straw contenders for this niche, my preference order continues
>> to be
>> * Traits
>
> If I had a vote, it would be +1
>
>> * Classes as Sugar
>> * Enhanced Object Literals
>>
>> But since Traits seems to be blocked from advancing,
>
> Is there someplace I should read to understand why Traits cannot advance?
>

I asked MarkM off-list what the reason was, and he replied that there
was an objection (raised by Waldemar?) to how class evolution was
handled. Namely, that adding a property P1 to trait X can cause a
cause a conflict in other downstream code that was already composing X
with Y where Y already had an independent property named P1.

In response to this, I outlined several possible ways forward:

1) pretend this issue doesn't exist and soldier on,

2) don't add traits,

3) perform automatic resolution in some sort of defined order based on
declaration (e.g., the C3 MRO algorithm that Python et. al uses),

4) perform automatic resolution based on some sort of runtime ordering
(e.g., last method added wins), (I'm not sure that this is actually
different from #3)

5) raise an exception when the conflict is detected, thereby forcing
the author to specify resolution (perhaps less appealing since we
don't necessarily have a "compile" phase to catch these errors at on a
web page).

Since the first option is surely unacceptable, and we'd like to not
have to settle on the second, that leaves the others. Most of the
people I've polled (including Tom van Cutsem) indicate a preference
for #5; Tom indicated that he thought one of the major goals of traits
was to avoid any sort of automatic resolution algorithm. Some are
unclear how much this will be a real problem in practice, and were
inclined to think that it shouldn't stop authors from being able to
use this (I'm probably paraphrasing incorrectly here), as long as they
are able to detect and recover from these issues.


More information about the es-discuss mailing list