Traits library

[Brendan Eich]

On Feb 19, 2010, at 9:33 AM, Kevin Curtis wrote:

> 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.

There's no need to ape the C Pre-Processor (@ not #, etc.). Please  
don't let that influence you. FYI, there's already an @if/@else/etc.  
preprocessor anguage in IE JScript.

Harmony has new syntax, with semantics defined by desugaring where  
doing so yields an unambiguous, abstraction-leak-free, and simple- 
enough and clear-enough spec that implementors (the primary spec  
audience) are most likely to create interoperable implementations.

The Harmony syntax, whatever it is (and some is approved, e.g.  
destructuring, spread, rest -- see http://wiki.ecmascript.org/doku.php?id=harmony:proposals) 
, can be translated to ES3+quirks, as needed.

The quirks may be more challenging than the relatively mundane  
(outside of generators) issues in targeting ES3.

The translation may have to work harder without @ to anchor its  
parsing or lexing (or regexp matching). The benefit is that users can  
program in the Harmony edition cross-browser. Let the translator  
authors bear the costs of parsing the full langage and "lowering" it  
to target old browsers.

/be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100219/e60ef4e6/attachment.html>