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
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
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
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 the
On Sun, Sep 5, 2010 at 6:33 PM, Mark S. Miller erig...@google.com 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
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
On Thu, Sep 9, 2010 at 10:37 PM, Brendan Eich bren...@mozilla.com 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
On Thu, Sep 9, 2010 at 10:37 PM, Brendan Eich bren...@mozilla.com 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
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
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.
2.
On Thu, Sep 9, 2010 at 11:31 PM, David Herman dher...@mozilla.com 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
On Fri, Sep 10, 2010 at 5:30 AM, David Herman dher...@mozilla.com 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
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
On Wed, Sep 8, 2010 at 10:16 AM, P T Withington p...@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,
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 feeling, and
On Wed, Sep 8, 2010 at 12:52 PM, David Herman dher...@mozilla.com 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
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 Waldemar?) to
On Sep 8, 2010, at 15:52, David Herman dher...@mozilla.com 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
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
On Sep 8, 2010, at 2:37 PM, P T Withington wrote:
On Sep 8, 2010, at 15:52, David Herman dher...@mozilla.com 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
On Wed, Sep 8, 2010 at 2:39 PM, David Herman dher...@mozilla.com 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
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 approach,
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
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
* Classes as Sugar
* Enhanced Object Literals
But since Traits seems to be blocked from advancing, I have now finally put
the Classes as
24 matches
Mail list logo
