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 difference is non-|this|-bounded objects are created). BTW there is another framework that was using traits for a long time http://joose.it/ not sure how widely adopted framework is though. Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ Address: 29 Rue Saint-Georges, 75009 Paris, France http://goo.gl/maps/3CHu On Sat, Sep 11, 2010 at 01:55, David Herman dher...@mozilla.com 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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 composition (or any other traditional inheritance mechanism). As long as this remains a deal-breaker, I don't think it's worth looking into alternative traits proposals. As Dave said, traits.js is out there for people to experiment with. Any feedback on usability issues of the design in its current form are highly appreciated. 2010/9/9 David Herman dher...@mozilla.com 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 actually review a proposal and see what the proposed benefits were? The latter (speaking for myself, of course). Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 the version evolution problem associated with trait composition (or any other traditional inheritance mechanism). As long as this remains a deal-breaker, I don't think it's worth looking into alternative traits proposals. As Dave said, traits.js is out there for people to experiment with. Any feedback on usability issues of the design in its current form are highly appreciated. I have on my to-do list to try re-casting the OpenLaszlo class framework as traits. Of the proposals for better class support in harmony, traits seems the most feasible to me for my work (we already translate to Ecmascript 3 and Actionscript 3). Clearly, I've got to actually implement it to test that theory. I certainly don't know any solution to the version evolution problem. AFAIK, it's why no one uses DLL's any more (or if they do, each app ships with its own private copy of every DLL it depends on). It's great that we can experiment with Traits without standardizing. It would be a shame to end up standardizing on an inferior proposal because of that feature of Traits. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Classes as Sugar is now ready for discussion
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 ECMAScript with delegation based prototypes does not differ much from a
class-based paradigm with first-class dynamic classes. The good example is
Python.
You won't find a big difference between Python's (first-class dynamic)
classes and prototypes+constructor in ECMAScript. Thus, the major aspects
should be considered: methods/properties resolution and code-reuse
stylistics. In both, ECMAScript and Python, a delegation based inheritance
is used to achieve both objectives. I.e. Python's classes are just syntactic
sugar of delegation based model used in ECMAScript.
Thus (the lacks of your desugarred code):
1. you don't have a good code-reuse mechanism (which should be used the same
-- a delegation to a class/prototype), i.e. every returned frozen instance
has own properties/methods that is non efficient.
2. you don't have an inheritance (again code-reuse, but the code of parent
prototypes).
Both lacks may be avoided even in ES5 implementation. Though, the desugarred
code will look ugly (with passing private state of objects to be able place
all methods -- private and public in to the prototype (public methods) and
its surrounding environment (private methods), having only one instance of a
method for for a class). Using new things such Names or WeakMaps possibly
it's even easier to achieve.
In your approach, there is a code-reuse, but it's made as cloning, but not
dispatching. Cloning (concatenative prototypes) is faster, but very
inefficient by memory. So, it's even may be called a smart copy-paste, but
not reuse (of the same memory).
The part of this strawman I am least happy is the rules of this at
http://wiki.ecmascript.org/doku.php?id=strawman:classes_as_sugar#delicate_self_reference.
Suggestions appreciated. Thanks.
The second one issue is that the sugar is not so sugarred. I think it should
syntactically be minimalistic and do not use several forms of
methods/functions (that will avoid the problem with /this/ value).
As I see it:
class Point(x, y) {
private:
var x = 10
var y = 20
function calculate(z) {
var x = 30
// use this to refer instance
// properties and distinguish from
// local var of a function
this.x + this.y + x + z
}
public:
var z = 30
function foo(z) {
this.bar() + this.calculate(z);
}
const function bar() {
this.z + 10
}
}
class MyPoint(x, ...args) inherits Point {
public:
function foo() {
super(this.x) + 30
}
}
Formal parameters may be moved to the initialize method. Also function
expressions may be used to define a method conditionally:
class MyPoint inherits Point {
public:
function initialize(x, ...args) {
this.x = x;
}
function foo() {
super(this.x) + 30
}
// a FE
function bar = debug ? (x, y) { ...} : (x) { ... };
}
P.S.: I mean, if you want a classes-sugar, then it really should be a shugar
and use all related things, including code-reuse implemented as delegation
based inheritance (thus a prototype may be frozen for static classes and not
-- for dynamic).
Dmitry.
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
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 Java). Insisting that we somehow come up with a mechanism to prevent conflicts seems like a pretty high bar; I'd like to hear more from people with such a view if that was indeed the blocking objection. -- Dirk On Thu, Sep 9, 2010 at 3:13 AM, Tom Van Cutsem tomvc...@gmail.com 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 version evolution problem associated with trait composition (or any other traditional inheritance mechanism). As long as this remains a deal-breaker, I don't think it's worth looking into alternative traits proposals. As Dave said, traits.js is out there for people to experiment with. Any feedback on usability issues of the design in its current form are highly appreciated. 2010/9/9 David Herman dher...@mozilla.com 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 actually review a proposal and see what the proposed benefits were? The latter (speaking for myself, of course). Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Classes as Sugar is now ready for discussion
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 versioning of words in Forth and, depending on how you look at it, the dynamic code loading mechanisms of Erlang (and class loaders in Java). Insisting that we somehow come up with a mechanism to prevent conflicts seems like a pretty high bar; I'd like to hear more from people with such a view if that was indeed the blocking objection. That would be Waldemar :-). Again, I feel it is important to say that everyone in TC39 who spoke up averred that traits.js is a well-written library, compelling in many ways. However, here are some other issues with the library, which need to be restated or presented properly so that Waldemar is not painted as sole spoiler: 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. I didn't know this till yesterday, but the Bespin (Skywriter, gag ;-) team at Mozilla tried using traits.js and had to stop, because it was consuming too much memory. I understand that this is from the pervasive use in the library of |this|-binding and copying to instance properties of all methods, along with other uses of closures. There is no prototypal sharing of method, or anything like vtables. Some of this could be optimized by aggressively-optimizing VMs, but it carries a heavy intrinsic cost. I think this is the key issue. Tom and I designed the traits library so that the expected common pattern of use would be easily optimizable by VMs, with no surprising intrinsic costs. If we missed the mark -- if there are indeed hidden costs lurking here that we missed -- that would be interesting. The expected common pattern which we expect to be optimizable needs to be stated clearly. Loosely, it is when trait composition is sufficiently statically analyzable that it can be expanded as if to a call to Trait.create with a literal property-descriptor-map argument. We also discussed that this is a good reason to couple VM support with special syntax -- so the special syntax can sugar only (primarily?) that pattern which can be handled efficiently. The full library would still be available for expressiveness of patterns that we don't expect VMs to optimize. 3. The design, in trying to catch conflicts, copies this-bound methods, freezes objects, and avoids prototype-based delegation. Beyond the costs in 2, this makes for a harshly bright line between Object.create and Trait.create, and although it is cool that the two systems complement each other, more traditional JS hackers arguably want prototype-based delegation, even though it may carry a shadowing conflict risk down the road. Some JS hackers even want mutability, with spot-checks for conflicts instead of for all/ever guarantees. These are not points we've discussed enough in committee, since we didn't talk about traits again since March. As noted, some details are news to me, but good to hear later instead of never. Points 2 and 3 are related: traits.js aims at higher integrity, for robust composition, than many JS hackers prefer and would choose (from what I hear, now -- I'd be happy to hear stories of successful adoption of the traitsjs.org code to counter the Bespin experience). A number of people, and I'm one of them having heard all the feedback so far (although I cited the costs listed in 2 on this list when the proposal was first posted), believe that this integrity trade-off should not be forced by blessing one fairly costly and near-extreme point in the trade-off space as a core language feature. This gets back to point 1. It also relates to the recent objections to zero-inheritance classes as sugar, which have high integrity but no inheritance. /be -- Dirk On Thu, Sep 9, 2010 at 3:13 AM, Tom Van Cutsem tomvc...@gmail.com 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 version evolution problem associated with trait composition (or any other traditional inheritance mechanism). As long as this remains a deal-breaker, I don't think it's worth looking into alternative traits proposals. As Dave said, traits.js is out there for people to experiment with. Any feedback on usability issues of the design in its current form are highly appreciated. 2010/9/9 David Herman dher...@mozilla.com Agreed; perhaps my question was not clear. If there was a Traits-like proposal that did include new
Re: Classes as Sugar is now ready for discussion
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 versioning of words in Forth and, depending on how you look at it, the dynamic code loading mechanisms of Erlang (and class loaders in Java). Insisting that we somehow come up with a mechanism to prevent conflicts seems like a pretty high bar; I'd like to hear more from people with such a view if that was indeed the blocking objection. That would be Waldemar :-). Again, I feel it is important to say that everyone in TC39 who spoke up averred that traits.js is a well-written library, compelling in many ways. However, here are some other issues with the library, which need to be restated or presented properly so that Waldemar is not painted as sole spoiler: 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. I didn't know this till yesterday, but the Bespin (Skywriter, gag ;-) team at Mozilla tried using traits.js and had to stop, because it was consuming too much memory. I understand that this is from the pervasive use in the library of |this|-binding and copying to instance properties of all methods, along with other uses of closures. There is no prototypal sharing of method, or anything like vtables. Some of this could be optimized by aggressively-optimizing VMs, but it carries a heavy intrinsic cost. 3. The design, in trying to catch conflicts, copies this-bound methods, freezes objects, and avoids prototype-based delegation. Beyond the costs in 2, this makes for a harshly bright line between Object.create and Trait.create, and although it is cool that the two systems complement each other, more traditional JS hackers arguably want prototype-based delegation, even though it may carry a shadowing conflict risk down the road. Some JS hackers even want mutability, with spot-checks for conflicts instead of for all/ever guarantees. These are not points we've discussed enough in committee, since we didn't talk about traits again since March. As noted, some details are news to me, but good to hear later instead of never. Points 2 and 3 are related: traits.js aims at higher integrity, for robust composition, than many JS hackers prefer and would choose (from what I hear, now -- I'd be happy to hear stories of successful adoption of the traitsjs.org code to counter the Bespin experience). Both the good and the bad news from the Bespin experience are exactly what Tom I expected in the absence of VM support. Also, the duality of Object.create vs Traits.create accommodates traditional vs high integrity quite well -- without AFAICT compromising either. A number of people, and I'm one of them having heard all the feedback so far (although I cited the costs listed in 2 on this list when the proposal was first posted), believe that this integrity trade-off should not be forced by blessing one fairly costly and near-extreme point in the trade-off space as a core language feature. This gets back to point 1. It also relates to the recent objections to zero-inheritance classes as sugar, which have high integrity but no inheritance. /be -- Dirk On Thu, Sep 9, 2010 at 3:13 AM, Tom Van Cutsem tomvc...@gmail.com 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 version evolution problem associated with trait composition (or any other traditional inheritance mechanism). As long as this remains a deal-breaker, I don't think it's worth looking into alternative traits proposals. As Dave said, traits.js is out there for people to experiment with. Any feedback on usability issues of the design in its current form are highly appreciated. 2010/9/9 David Herman dher...@mozilla.com 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 actually review a proposal and see what the proposed benefits were? The latter (speaking for myself, of course). Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org
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 the key benefit of traits. I think there's room for alternatives in the traits space -- for example, something similar wrt trait composition, but that didn't bind |this| or freeze. That way, you could still integrate traits with the existing prototype system. For example, to compose traits to create an object that you then use as the prototype for a constructor. This would allow for the vtables approach and would also give you the ability to specify initialization behavior to invoke on instantiation, which you can't do with traits.js. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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. 2. I didn't know this till yesterday, but the Bespin (Skywriter, gag ;-) team at Mozilla tried using traits.js and had to stop, because it was consuming too much memory. I understand that this is from the pervasive use in the library of |this|-binding and copying to instance properties of all methods, along with other uses of closures. There is no prototypal sharing of method, or anything like vtables. Some of this could be optimized by aggressively-optimizing VMs, but it carries a heavy intrinsic cost. I think this is the key issue. Points 1 and 3 are worth addressing, if you are game. Tom and I designed the traits library so that the expected common pattern of use would be easily optimizable by VMs, with no surprising intrinsic costs. If we missed the mark -- if there are indeed hidden costs lurking here that we missed -- that would be interesting. You may recall the posts I made at the time: https://mail.mozilla.org/pipermail/es-discuss/2010-February/010830.html https://mail.mozilla.org/pipermail/es-discuss/2010-February/010832.html The expected common pattern which we expect to be optimizable needs to be stated clearly. Loosely, it is when trait composition is sufficiently statically analyzable that it can be expanded as if to a call to Trait.create with a literal property-descriptor-map argument. We also discussed that this is a good reason to couple VM support with special syntax -- so the special syntax can sugar only (primarily?) that pattern which can be handled efficiently. The full library would still be available for expressiveness of patterns that we don't expect VMs to optimize. It's true, syntax can help optimizability (and usability). But we never heard a proposal and it's hard to make one up without worrying about how |this|-binding works in detail, e.g. Does a call go through a vtable in the case where the method is invoked via a property reference, otherwise a bound method object is created (for the escaping funarg case)? And so on, in sufficient detail to see a path to trial implementation and interoperable observable semantics, including approximate or asymptotic cost models. /be 3. The design, in trying to catch conflicts, copies this-bound methods, freezes objects, and avoids prototype-based delegation. Beyond the costs in 2, this makes for a harshly bright line between Object.create and Trait.create, and although it is cool that the two systems complement each other, more traditional JS hackers arguably want prototype-based delegation, even though it may carry a shadowing conflict risk down the road. Some JS hackers even want mutability, with spot-checks for conflicts instead of for all/ever guarantees. These are not points we've discussed enough in committee, since we didn't talk about traits again since March. As noted, some details are news to me, but good to hear later instead of never. Points 2 and 3 are related: traits.js aims at higher integrity, for robust composition, than many JS hackers prefer and would choose (from what I hear, now -- I'd be happy to hear stories of successful adoption of the traitsjs.org code to counter the Bespin experience). A number of people, and I'm one of them having heard all the feedback so far (although I cited the costs listed in 2 on this list when the proposal was first posted), believe that this integrity trade-off should not be forced by blessing one fairly costly and near-extreme point in the trade-off space as a core language feature. This gets back to point 1. It also relates to the recent objections to zero-inheritance classes as sugar, which have high integrity but no inheritance. /be -- Dirk On Thu, Sep 9, 2010 at 3:13 AM, Tom Van Cutsem tomvc...@gmail.com 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 version evolution problem associated with trait composition (or any other traditional inheritance mechanism). As long as this remains a deal-breaker, I don't think it's worth looking into alternative traits proposals. As Dave said, traits.js is out there for people to experiment with. Any feedback on usability issues of the design in its current form are highly appreciated. 2010/9/9 David Herman dher...@mozilla.com 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
Re: Classes as Sugar is now ready for discussion
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 choice. What makes a choice false? The traits library is an
open abstraction -- it doesn't encapsulate anything; it only provides some
conveniences for sets of choices that seem to go together. It doesn't
preclude others from making other choices, or from providing further
abstractions for making those choices convenient.
Of course, that doesn't mean we've chosen the right set of knobs. A better
set of knobs would be great. But, IMO, simply having more knobs wouldn't be.
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.create, you still get conflict detection, but with failure
postponed from creation to usage. This is a more traditionally JavaScripty
way to report failure anyway.
I think there's room for alternatives in the traits space -- for example,
something similar wrt trait composition, but that didn't bind |this| or
freeze. That way, you could still integrate traits with the existing
prototype system. For example, to compose traits to create an object that
you then use as the prototype for a constructor. This would allow for the
vtables approach and would also give you the ability to specify
initialization behavior to invoke on instantiation, which you can't do with
traits.js.
Yes you can:
function Point(x, y) {
this.x = x;
this.y = y;
}
Point.prototype = Object.create(
SuperPoint.prototype,
Trait.compose(.));
Is that the kind of usage you had in mind?
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Classes as Sugar is now ready for discussion
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 Object.create, you still get conflict detection, but with failure
postponed from creation to usage. This is a more traditionally JavaScripty
way to report failure anyway.
Ah, I see. I missed that part.
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.create. As Tom was implementing our design, he noticed that the low
integrity case simplified down to being identical to Object.create. Seeing
that, Tom realized that we didn't actually need a switch as people could
just use Object.create directly.
Tom, do I have the history of that right?
function Point(x, y) {
this.x = x;
this.y = y;
}
Point.prototype = Object.create(
SuperPoint.prototype,
Trait.compose(.));
Is that the kind of usage you had in mind?
Yes, exactly. Sorry for my oversight.
Dave
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
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 But since Traits seems to be blocked from advancing, Is there someplace I should read to understand why Traits cannot advance? I have now finally put the Classes as Sugar strawman on the agenda for consideration by the committee. It is now ready for discussion. This: Inheritance using the prototype chain does not work since the members are added to the instance and not the prototype. This makes this proposal non compatible with existing JavaScript paradigms. This in turn leads to classes becoming something completely new that exists on the side of existing best practices of doing OOP in JS. seems damning, without further explanation. Enough so that I would say the proposal should not use the word class to describe what it does. From a users point of view, it is baffling why you would want to standardize something so non-standard, when there is a clear call from use cases for a standard for doing normal OOP in Javascript. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Classes as Sugar is now ready for discussion
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, it would be +1 * Classes as Sugar * Enhanced Object Literals 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. Namely, that adding a property P1 to trait X can cause a cause a conflict in other downstream code that was already composing X with Y where Y already had an independent property named P1. In response to this, I outlined several possible ways forward: 1) pretend this issue doesn't exist and soldier on, 2) don't add traits, 3) perform automatic resolution in some sort of defined order based on declaration (e.g., the C3 MRO algorithm that Python et. al uses), 4) perform automatic resolution based on some sort of runtime ordering (e.g., last method added wins), (I'm not sure that this is actually different from #3) 5) raise an exception when the conflict is detected, thereby forcing the author to specify resolution (perhaps less appealing since we don't necessarily have a compile phase to catch these errors at on a web page). Since the first option is surely unacceptable, and we'd like to not have to settle on the second, that leaves the others. Most of the people I've polled (including Tom van Cutsem) indicate a preference for #5; Tom indicated that he thought one of the major goals of traits was to avoid any sort of automatic resolution algorithm. Some are unclear how much this will be a real problem in practice, and were inclined to think that it shouldn't stop authors from being able to use this (I'm probably paraphrasing incorrectly here), as long as they are able to detect and recover from these issues. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 feeling, and I think the feeling of others at the meeting when we discussed traits, was that traits.js is a very nice library but that it doesn't offer enough to the language to warrant standardization, at least yet. The fact that there would be performance benefits to built-in implementations of traits isn't enough to make the case. IMO, libraries should generally be very widely used and very stable before they are added to the ES standard library. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Classes as Sugar is now ready for discussion
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 (raised by Waldemar?) to how class evolution was handled. My feeling, and I think the feeling of others at the meeting when we discussed traits, was that traits.js is a very nice library but that it doesn't offer enough to the language to warrant standardization, at least yet. The fact that there would be performance benefits to built-in implementations of traits isn't enough to make the case. IMO, libraries should generally be very widely used and very stable before they are added to the ES standard library. Does that feeling carry over to any variants that might actually include new syntax? -- Dirk ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 Waldemar?) to how class evolution was handled. My feeling, and I think the feeling of others at the meeting when we discussed traits, was that traits.js is a very nice library but that it doesn't offer enough to the language to warrant standardization, at least yet. The fact that there would be performance benefits to built-in implementations of traits isn't enough to make the case. IMO, libraries should generally be very widely used and very stable before they are added to the ES standard library. The specific objection articulated by Waldemar was the version evolution problem, where a downstream client and upstream library evolve independent, conflicting traits. If I remember Waldemar's point correctly, he wants version 1 library users to be shielded from any conflict between their client code, however it evolves, and version 2 of the library, however it evolves. AFAIK this is nowhere near a solved problem in PLT. The general objection, or more accurately, recommendation (since everyone I know thinks highly of Mark and Tom's http://traitsjs.org work), was what Dave said: the code was too good as library code to win hardcoding in dedicated syntax in a near-term edition of ECMA-262. I pointed out on this list that JS VMs have a hard time optimizing traits' shared methods -- really, optimizing away multiple function objects resulting from evaluation of a single nested function expression or definition: https://mail.mozilla.org/pipermail/es-discuss/2010-February/010830.html https://mail.mozilla.org/pipermail/es-discuss/2010-February/010832.html But this problem can be solved by an extension such as http://wiki.ecmascript.org/doku.php?id=strawman:const_functions Specifically the bit I proposed at the July TC39 meeting at Microsoft, which Mark nicely wrote up in detail at http://wiki.ecmascript.org/doku.php?id=strawman:const_functions#joining So if traits.js does not need syntax to be optimized, it still might merit syntax for usability. But we would need more experience with it, and a larger user base for it, before standardizing. We in TC39 generally hesitate to standardize library code. We certainly extended the JS standard library in ES5, but notably with JSON, which is a fixed spec that will never change (only be replaced some day, Doug says -- that day is far off, I say). The ES5 meta-programming API was a synthesis and extended rationalization of precursors such as getters and setters including their __ APIs (__lookupGetter__, etc.) first added by Mozilla over ten years ago, and cloned into other browsers. Function.prototype.bind was a common feature of JS libraries, although not always the same and we're only now finding conflicts (with MooTools, which is adapting to avoid the conflict, IIRC). This was more than enough library extension for ES5, and with implementations only rolling out now in betas or preview releases, the verdict on how well we did is not yet in. I am sympathetic to objections of the form Ecma TC39 should not under-evolve the language and its standard library and thereby require all developers to develop and download big non-standard libraries, but it is not the only consideration. On the other side, library standardization should never be rushed. Just look at what happened with C! We really do not have the competence in TC39 (no one group does, yet, IMHO) to standardize JS library code aggressively. There are indeed notorious language and library gaps to fill, but we are focusing on the language gaps, with the Scheme philosophy of adding missing primitives that compose well and have good general usability and safety, while treading carefully with the library gaps. Traits could be part of the standard library at some point if they become popular to the same degree as JSON or bind, and provided we can overcome Waldemar's objection. Waldemar has been concerned with the version evolution problem since the original JS2/ES5 days. But we failed to solve it with ES4, so I'm not going to hold out for utopia (no-place). JS is a worse-is-better language, too much so, but getting over it. JS is never to be a superb better-is-better (which usually means never-is-better, which means users hacking library and app code have to reinvent wheels constantly) language. Parting shot: I find the zero-inheritance classes-as-sugar proposal to be lukewarm beer, and want to spit it out. I'm with Tucker. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Classes as Sugar is now ready for discussion
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 implemented as a library (despite being a more experimental approach, and at odds with existing OOP libraries)? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 say that we should *never* add new already-implementable libraries to the standard. Sometimes they fill an obvious hole (like Array.prototype.forEach), or they are clear, stable, and popular (like JSON). Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 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 [is] preferred because it _can't_ be implemented as a library (despite being a more experimental approach, and at odds with existing OOP libraries)? I would not say classes-as-sugar is preferred by everyone on TC39. Waldemar favored it over against traits so Mark went back to the wiki salt mine to work on it. Hard to say what will happen here -- possibly something else (object initialiser extensions). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Classes as Sugar is now ready for discussion
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 completely implementable as a library in the existing language. 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 actually review a proposal and see what the proposed benefits were? -- Dirk ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 approach, and at odds with existing OOP libraries)? No. But keep in mind that nobody's denying anyone of the traits library. Go to http://traitsjs.org and use it today! :) IOW, I think it's better to focus on the things that can't otherwise be done in user code. Blessing certain existing libraries with possibly-more-performant C++ implementations is not a good use of committee resources, and it's a bad way to release and rev software since it's so much more encumbered by process. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 actually review a proposal and see what the proposed benefits were? The latter (speaking for myself, of course). Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
