Re: Classes as Sugar is now ready for discussion

On 13.09.2010 12:30, Dmitry A. Soshnikov wrote: 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 pr

Re: Classes as Sugar is now ready for discussion

On 13.09.2010 12:11, Irakli Gozalishvili wrote: Hi, Not a long time ago we also started using traits at [Jetpack](http://mozillalabs.com/jetpack/) and so far it seems to work pretty well for us. In contrast to bespin though we don't use traitsjs.org instead we have our

Re: Classes as Sugar is now ready for discussion

Hi, Not a long time ago we also started using traits at [Jetpack]( http://mozillalabs.com/jetpack/) and so far it seems to work pretty well for us. In contrast to bespin though we don't use traitsjs.org instead we have our own implementation which pretty much follows same APIs (one major differenc

Re: Classes as Sugar is now ready for discussion

> 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

Re: Classes as Sugar is now ready for discussion

:s/niche/demand 2010/9/10 Tom Van Cutsem > Is the on-demand nature of conflict detection (for traits built with >>> Object.create) somehow unavoidable, or was that simply a design choice? >>> >> >> It actually was a design choice dating from before we switched to >> Object.create. Originally, we

Re: Classes as Sugar is now ready for discussion

> > Is the on-demand nature of conflict detection (for traits built with >> Object.create) somehow unavoidable, or was that simply a design choice? >> > > It actually was a design choice dating from before we switched to > Object.create. Originally, we had a high-vs-low integrity switch in > Traits

Re: Classes as Sugar is now ready for discussion

On Fri, Sep 10, 2010 at 5:30 AM, David Herman wrote: > IIUC, with Object.create, you don't even get the conflict checking. And >> then you've really lost the key benefit of traits. >> > > See < > http://code.google.com/p/es-lab/source/browse/trunk/src/traits/traits.js#150>. > Even with Object.cre

Re: Classes as Sugar is now ready for discussion

> IIUC, with Object.create, you don't even get the conflict checking. And then > you've really lost the key benefit of traits. > > See > . > Even with Object.create, you still get conflict detection, but with failure

Re: Classes as Sugar is now ready for discussion

On Thu, Sep 9, 2010 at 11:31 PM, David Herman wrote: > > Also, the duality of Object.create vs Traits.create accommodates > traditional vs high integrity quite well -- without AFAICT compromising > either. > > It creates a false choice, though (all or nothing). It does create a choice. What mak

Re: Classes as Sugar is now ready for discussion

On Sep 9, 2010, at 4:06 PM, Mark S. Miller wrote: > 1. It's premature to standardize something so new. Again, the "Array extras" > (map, filter, etc.) have been a de-facto standard for years, getters and > setters for over a decade, bind-like library methods and JSON for quite a > long while. >

Re: Classes as Sugar is now ready for discussion

> Also, the duality of Object.create vs Traits.create accommodates traditional > vs high integrity quite well -- without AFAICT compromising either. It creates a false choice, though (all or nothing). IIUC, with Object.create, you don't even get the conflict checking. And then you've really lost

Re: Classes as Sugar is now ready for discussion

On Thu, Sep 9, 2010 at 10:37 PM, Brendan Eich wrote: > On Sep 9, 2010, at 3:06 PM, Dirk Pranke wrote: > > As Brendan pointed out, the version evolution problem is nowhere near > a solved issue in language design; the only approaches I know of that > get close to it are the versioning of words in

Re: Classes as Sugar is now ready for discussion

On Thu, Sep 9, 2010 at 10:37 PM, Brendan Eich wrote: > On Sep 9, 2010, at 3:06 PM, Dirk Pranke wrote: > > As Brendan pointed out, the version evolution problem is nowhere near > a solved issue in language design; the only approaches I know of that > get close to it are the versioning of words in

Re: Classes as Sugar is now ready for discussion

On Sep 9, 2010, at 3:06 PM, Dirk Pranke wrote: > As Brendan pointed out, the version evolution problem is nowhere near > a solved issue in language design; the only approaches I know of that > get close to it are the versioning of words in Forth and, depending on > how you look at it, the dynamic

Re: Classes as Sugar is now ready for discussion

As Brendan pointed out, the version evolution problem is nowhere near a solved issue in language design; the only approaches I know of that get close to it are the versioning of words in Forth and, depending on how you look at it, the dynamic code loading mechanisms of Erlang (and class loaders in

Re: Classes as Sugar is now ready for discussion

Sorry, my understanding of these proposals is limited, but did I miss something about class-as-sugar: Does it provide any inheritance/mixin capability? Also, has anyone considered: http://jsclass.jcoglan.com/classes.html ___ es-discuss mailing list es

Re: Classes as Sugar is now ready for discussion

On Sun, Sep 5, 2010 at 6:33 PM, Mark S. Miller wrote: > http://wiki.ecmascript.org/doku.php?id=strawman:classes_as_sugar > > * Classes as Sugar > > All this looks a bit strange. From several positions. First, combination of classes and prototypes. Currently, the paradigm used in ECMAScript with

Re: Classes as Sugar is now ready for discussion

On 2010-09-09, at 06:13, Tom Van Cutsem wrote: > There's no mistake that dedicated syntax for traits would help users and > implementors alike. However, while I (or others) could definitely come up > with a 'traits-as-sugar', or even a 'traits-as-a-new-value' proposal, that > still wouldn't solve

Re: Classes as Sugar is now ready for discussion

There's no mistake that dedicated syntax for traits would help users and implementors alike. However, while I (or others) could definitely come up with a 'traits-as-sugar', or even a 'traits-as-a-new-value' proposal, that still wouldn't solve the version evolution problem associated with trait comp

Re: Classes as Sugar is now ready for discussion

> Agreed; perhaps my question was not clear. If there was a Traits-like > proposal that did include new syntax, would you be against it because > you can implement something similar as a library without needing new > semantics, or would you be more inclined to reserve judgement until > you could ac

Re: Classes as Sugar is now ready for discussion

>> libraries should generally be very widely used and very stable before they >> are added to the ES standard library. > > That would seem like an unfair penalty. Am I to infer classes-as-sugar OS > preferred because it _can't_ be implemented as a library (despite being a > more experimental ap

Re: Classes as Sugar is now ready for discussion

On Wed, Sep 8, 2010 at 2:39 PM, David Herman wrote: >> Does that feeling carry over to any variants that might actually >> include new syntax? > > The issue isn't whether it introduces new syntax, it's whether it introduces > new semantics. The Traits library, as written, is completely implementa

Re: Classes as Sugar is now ready for discussion

On Sep 8, 2010, at 2:37 PM, P T Withington wrote: > On Sep 8, 2010, at 15:52, David Herman wrote: > >> libraries should generally be very widely used and very stable before they >> are added to the ES standard library. > > That would seem like an unfair penalty. Am I to infer classes-as-sugar

Re: Classes as Sugar is now ready for discussion

> Does that feeling carry over to any variants that might actually > include new syntax? The issue isn't whether it introduces new syntax, it's whether it introduces new semantics. The Traits library, as written, is completely implementable as a library in the existing language. That's not to s

Re: Classes as Sugar is now ready for discussion

On Sep 8, 2010, at 15:52, David Herman wrote: > libraries should generally be very widely used and very stable before they > are added to the ES standard library. That would seem like an unfair penalty. Am I to infer classes-as-sugar OS preferred because it _can't_ be implemented as a library

Re: Classes as Sugar is now ready for discussion

On Sep 8, 2010, at 1:11 PM, Dirk Pranke wrote: > On Wed, Sep 8, 2010 at 12:52 PM, David Herman wrote: > 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

Re: Classes as Sugar is now ready for discussion

On Sep 8, 2010, at 12:52 PM, David Herman wrote: 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

Re: Classes as Sugar is now ready for discussion

On Wed, Sep 8, 2010 at 12:52 PM, David Herman wrote: 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 b

Re: Classes as Sugar is now ready for discussion

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

Re: Classes as Sugar is now ready for discussion

On Wed, Sep 8, 2010 at 10:16 AM, P T Withington 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,

Re: Classes as Sugar is now ready for discussion

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