Traits library

[Kevin Curtis]

Kam, interesting point. The same issues apply to modules as well as traits:

- module {} vs Module()
- new syntax vs ES5-ish Meta Api
- compile time vs runtime

Could macros - or some kind of AOP-ish compile time processing - help:
@addtrait mytrait myobj;
@import acme.mymod; // expands to const acme = {mymod: {myfunc: ...;

An ES-Harmony goal is to: "Provide syntactic conveniences ...defined by
desugaring into kernel semantics."
How could this be achieved? Macro source expansion? What is truly new
'kernel semantics' as opposed to syntax sugar? Interesting stuff.


On Fri, Feb 19, 2010 at 3:29 PM, Kam Kasravi <kamkasravi at yahoo.com> wrote:

> Hi Brendan
>
> Picking up where Tom left off below...   I've wondered how you and the
> ECMAScript body prefer to have
> particular concepts presented. Given that the lag time between new syntax
> and conformance across vendors
> could be months, years or never, it seems that there is always a need to
> provide a 'shim'
> or implementation that emulates proposed syntax. I think many concepts
> including Tom and Mark's
> steer away from new syntax due to the problems noted.  In general should
> there be due diligence on both?
> I realize this may vary per strawperson but thought you may have a general
> philosophy to share.
>
> thx
> kam
>
> ------------------------------
> *From:* Tom Van Cutsem <tomvc at google.com>
> *To:* Brendan Eich <brendan at mozilla.com>
> *Cc:* Mark S. Miller <erights at google.com>; es-discuss Steen <
> es-discuss at mozilla.org>
> *Sent:* Thu, February 18, 2010 11:09:18 AM
> *Subject:* Re: Traits library
>
> Put together the user and implementor taxes, and you have sufficient cause
>> for new syntax.
>>
>> Add to this tax revolt the plain desire for better
>> syntax-as-user-interface. If you want const f(){}, why //wouldn't// you want
>> declarative trait syntax?
>
>
> Hi Brendan,
>
> Thanks for enlightening us with the implementation-level issues involved in
> getting user-land traits optimized. That definitely puts things in
> perspective. I wholeheartedly agree that dedicated syntax would be of great
> help to users, and to implementors as a not-to-be-underestimated bonus.
>
> I am not at all opposed to dedicated syntax/semantics for traits in
> ES-harmony. Think of traits.js more as an exercise in exploring the design
> space of what is possible today. For example, the fact that ES5's property
> descriptor maps turned out to be directly usable as traits was a surprising
> new insight to me.
>
> I think the most useful outcome of this experiment is that it gives us a
> better idea of what the fundamental limits of a library approach are. For
> example: that syntax for traits is (mostly) not a boilerplate issue but a
> semantic issue (early error feedback) + an implementation issue (method
> sharing).
>
> And who knows, if there is an uptake of this library in ES5, it would help
> familiarize programmers with traits without them having to wait for
> dedicated syntax. But I am aware that this is very optimistic: many have
> previously designed good class, mixin and even trait libraries for ES3, and
> to the best of my knowledge, none of these seem to have widely caught on.
>
> Cheers,
> Tom
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100219/28414430/attachment.html>