Classes as Sugar is now ready for discussion

Dmitry A. Soshnikov dmitry.soshnikov at
Mon Sep 13 01:30:38 PDT 2010

  On 13.09.2010 12:11, Irakli Gozalishvili wrote:
> Hi,
> Not a long time ago we also started using traits at 
> [Jetpack]( and so far it seems to work 
> pretty well for us. In contrast to bespin though we don't use 
> <> instead we have our own 
> implementation which pretty much follows same APIs (one major 
> difference is non-|this|-bounded objects are created).

Regarding non-|this|-bounded -- yeah, I think that it's better to use 
exactly a delegation and reuse functions from mixed modules. Despite 
that properties are references to the same objects, augmented (with 
traits or mixins) objects have own properties, that decreases reusing 
(if to remove a function from a trait, it still will be exists in the 
augmented object). Currently, it's easily possible to implement 
delegation based traits/mixins even in ES3 (though, with non-standard 
extenstion such as __proto__ and __noSuchMethod__, for example: With using new Proxies (and possibly 
WeakMap) mechanism it's should be possible to implement them for Harmony.

Also, regarding syntax: it would be good to have these new concepts 
syntactically minimalized (it's too long/boring) to write every time: 
Trait.create-Trait.required-Trait-compose-Trait-required-etc. Possibly, 
a new keyword (that I saw used in other languages) would be good (if of 
course traits will be accepted):

trait Enumerable {
   required: ["forEach"],
   map: (item) {

class Hash extends Object {
   include Enumerable
     function handleItem() {
     function get() {}
     function set() {}

P.S.: Though, I noticed that all Marks / Toms examples are penetrated 
with /const/ and /freeze/ keywords, just as it's a static language (in a 
function, e.g. there are only const-const-const -- for variables or 
functions -- no matter and then the frozen object is returned). Maybe 
because of that they used "bound-this" and "non-inheritable 


> BTW there is another framework that was using traits for a long time 
> not sure how widely adopted framework is though.
> Regards
> --
> Irakli Gozalishvili
> Web:
> Address: 29 Rue Saint-Georges, 75009 Paris, France 
> <>
> On Sat, Sep 11, 2010 at 01:55, David Herman <dherman at 
> <mailto:dherman at>> wrote:
>     > Yes, that's an accurate summary. It also brings me back to
>     Dave's earlier question about the limited choices provided by the
>     Traits library.
>     > ...
>     > Long story short: it's definitely possible for a Traits library
>     to offer more knobs, although I'm not sure whether the increased
>     complexity is worth it.
>     Just to be clear, I wasn't saying we should consider *more* knobs,
>     just that other knobs are possible. I'm not convinced that the
>     Trait.create knob offered by traits.js is necessary.
>     > Judging from earlier comments, it seems there is at least a
>     niche for the combination of 'early conflict detection' +
>     'non-frozen, non-|this|-bound objects'.
>     I'm told this is what our colleagues working on Skywriter would
>     have preferred.
>     Dave
>     _______________________________________________
>     es-discuss mailing list
>     es-discuss at <mailto:es-discuss at>
> _______________________________________________
> es-discuss mailing list
> es-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list