r-proto-class

Hi, R-proto-class is my quick experiment of yet another class lib for ES5: https://gist.github.com/1366953 Main features are: * Simple super calls (with mentioned before, but modified, "delete-restore" parent link); used only for classes. * using Object.create for inheritance (the main

Re: r-proto-class

You fell for the broken super implementation trap Your calling super methods with a value of `this` that has references to methods you don't expect it to have. i.e. if any sub class shadows a method of a super class, then every reference to method invocation in the su

Re: r-proto-class

On 15.11.2011 17:34, Jake Verbaten wrote: You fell for the broken super implementation trap Your calling super methods with a value of `this` that has references to methods you don't expect it to have. i.e. if any sub class shadows a method of a super class, the

Demo: static super references

FWIW: I’ve created a gist that demonstrates static super references (in the manner that Allen proposes them). https://gist.github.com/1367052 -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___

Re: r-proto-class

AFAIKT, your way of super-calling won’t work: - When starting at the instance you skip the instance’s prototype. - During each recursive call, you advance one object in the prototype chain. That won’t work if a super-method is not in the next object (that is, if there are holes in the chain). Ev

Re: r-proto-class

> > Anyway, once again, the main point I wanted to note, is that we _already_ > may have more-less good classes via libs with more-less acceptable > convenient super-calls. The standardized version should be better that all > the libs. I.e.: (1) not to have the issue you describe and (2) which IMO

Re: r-proto-class

> > Even with adding properties to objects (which is a no-no for ES.next), > dynamic super is never particularly elegant. This was the best solution I > could come up with and it’s not pretty: https://gist.github.com/1331748 > If we could get away with manipulating the prototype chain at run time

Re: r-proto-class

On 15.11.2011 18:13, Jake Verbaten wrote: Even with adding properties to objects (which is a no-no for ES.next), dynamic super is never particularly elegant. This was the best solution I could come up with and it’s not pretty: https://gist.github.com/1331748 Is it based on th

Re: r-proto-class

>> Even with adding properties to objects (which is a no-no for ES.next), >> dynamic super is never particularly elegant. This was the best solution I >> could come up with and it’s not pretty: https://gist.github.com/1331748 > > Is it based on the technique I showed before? Nice :) Though, wher

Re: Demo: static super references

On 15.11.2011 18:02, Axel Rauschmayer wrote: FWIW: I’ve created a gist that demonstrates static super references (in the manner that Allen proposes them). https://gist.github.com/1367052 Also shown millions of times (e.g. https://github.com/DmitrySoshnikov/def.js/blob/master/def.js#L82). With

Re: Demo: static super references

On 15.11.2011 18:34, Dmitry Soshnikov wrote: On 15.11.2011 18:02, Axel Rauschmayer wrote: FWIW: I’ve created a gist that demonstrates static super references (in the manner that Allen proposes them). https://gist.github.com/1367052 Also shown millions of times (e.g. https://github.com/Dmitry

Re: Demo: static super references

It’s not a big deal, just an illustration of Allen’s work. On Nov 15, 2011, at 15:34 , Dmitry Soshnikov wrote: > On 15.11.2011 18:02, Axel Rauschmayer wrote: >> FWIW: I’ve created a gist that demonstrates static super references (in the >> manner that Allen proposes them). >> >> https://gist.gi

migrating `let' and `const'

Hello, Do I have it right that the intention with `let' and `const' is to allow them in strict mode? SpiderMonkey appears to allow them, as does V8 with --harmony, but V8 without --harmony and JSC both abort on `const' in strict mode. Likewise, none of the major engines abort on `const' in non-s

Re: migrating `let' and `const'

On Nov 15, 2011, at 7:17 AM, Andy Wingo wrote: > Hello, > > Do I have it right that the intention with `let' and `const' is to allow > them in strict mode? > > SpiderMonkey appears to allow them, as does V8 with --harmony, but V8 > without --harmony and JSC both abort on `const' in strict mode.

Re: migrating `let' and `const'

On Tue, 2011-11-15 at 07:41 -0800, Brendan Eich wrote: > To quote Waldemar from > > https://mail.mozilla.org/pipermail/es-discuss/2010-October/011972.html > > "It's a judgment call, and I'd take these on a case-by-case basis. > For const and let, I see little harm in browsers allowing them now i

Re: The class operator: a bridge between object and function exemplers

Sorry I'm late to the party, I'm just catching up now. I'm glad that what I proposed got mentioned (thanks Brendan), but I wanted to be clear that its not actually what Allen is proposing here. Where Allen is proposing a simple sugar operator to retrieve the constructor, I was proposing an operator

Re: The class operator: a bridge between object and function exemplers

On Nov 15, 2011, at 8:16 AM, Russell Leggett wrote: > ... > > As has been said, a missing constructor would not result in the expected > behavior. I can also imagine other scenarios where the behavior would be > unusual. I agree, there is an issue with missing constructors. Certainly my

Re: r-proto-class

On 15.11.2011 17:49, Dmitry Soshnikov wrote: On 15.11.2011 17:34, Jake Verbaten wrote: You fell for the broken super implementation trap Your calling super methods with a value of `this` that has references to methods you don't expect it to have. i.e. if any sub

Re: The class operator: a bridge between object and function exemplers

On Monday, 2011-11-14 at 16:50 , David Flanagan wrote: > On 11/14/11 4:16 PM, Allen Wirfs-Brock wrote: > > On Nov 14, 2011, at 3:15 PM, David Flanagan wrote: > > > I have a bad feeling about making 'new' work with both functions and > > > object exemplars. If we can have two different types of

Re: The class operator: a bridge between object and function exemplers

Sorry I'm so excited about this that I just could not read it all before posting this, my apologies if it's already discussed: On Monday, 2011-11-14 at 17:04 , Allen Wirfs-Brock wrote: > > > > > > > >UnaryExpression : > > > >class UnaryExpression > > > >... > > >

Re: The class operator: a bridge between object and function exemplers

On Nov 15, 2011, at 8:16 AM, Russell Leggett wrote: > I think this example is contrived, but illustrates the point that JavaScript > is very dynamic, and sometimes in the building process an object can be out > of sync from its constructor. My expectations when I see this would be that > my res

Re: The class operator: a bridge between object and function exemplers

On Nov 15, 2011, at 9:56 AM, Brendan Eich wrote: > On Nov 15, 2011, at 8:16 AM, Russell Leggett wrote: > >> I think this example is contrived, but illustrates the point that JavaScript >> is very dynamic, and sometimes in the building process an object can be out >> of sync from its constructor

Re: migrating `let' and `const'

On 11/15/2011 07:17 AM, Andy Wingo wrote: SpiderMonkey appears to allow them, as does V8 with --harmony, but V8 without --harmony and JSC both abort on `const' in strict mode. If you opt into a version supporting 'let', you get 'let' functionality. If you don't, 'let' is a strict reserved key

Re: The class operator: a bridge between object and function exemplers

On 11/14/11 3:01 PM, Allen Wirfs-Brock wrote: On Nov 14, 2011, at 2:01 PM, Brendan Eich wrote: On Nov 14, 2011, at 12:16 PM, Allen Wirfs-Brock wrote: let Point = { x:0, y,0, constructor(x,y} { this.x=x; this.y=y; } }.constructor; //<--- note ad

Re: The class operator: a bridge between object and function exemplers

On Tue, Nov 15, 2011 at 1:01 PM, Brendan Eich wrote: > On Nov 15, 2011, at 9:56 AM, Brendan Eich wrote: > > > On Nov 15, 2011, at 8:16 AM, Russell Leggett wrote: > > > >> I think this example is contrived, but illustrates the point that > JavaScript is very dynamic, and sometimes in the building

Re: The class operator: a bridge between object and function exemplers

On 11/14/11 5:17 PM, Allen Wirfs-Brock wrote: On Nov 14, 2011, at 4:50 PM, David Flanagan wrote: On 11/14/11 4:16 PM, Allen Wirfs-Brock wrote: On Nov 14, 2011, at 3:15 PM, David Flanagan wrote: I have a bad feeling about making 'new' work with both functions and object exemplars. If we can

Re: The class operator: a bridge between object and function exemplers

On Tuesday, 2011-11-15 at 10:58 , David Flanagan wrote: > On 11/14/11 5:17 PM, Allen Wirfs-Brock wrote: > > On Nov 14, 2011, at 4:50 PM, David Flanagan wrote: > > > > > On 11/14/11 4:16 PM, Allen Wirfs-Brock wrote: > > > > On Nov 14, 2011, at 3:15 PM, David Flanagan wrote: > > > > > I have a ba

Re: r-proto-class

On 15.11.2011 17:34, Jake Verbaten wrote: You fell for the broken super implementation trap By the way, forgot to mention. In dynamic languages it may be dependent. And it's actually a question what is a correct behavior -- early or late binding in this case.

Re: Standard @iter module unfriendly to collection builders

On Sun, Nov 13, 2011 at 12:17 PM, Erik Arvidsson wrote: > Another thing to consider is whether these functions belong in an iter > module or in a reflect module? I'm leaning towards the letter. I completely agree. for-of should be the tool for iterating over collections. We should make it super

Re: Standard @iter module unfriendly to collection builders

To address Allen's original question: I think the Map and Set classes in Harmony mean that not all structured data is stored as object properties. I think that's a good thing. However it does mean that we must have a separation of concerns between - iterating over a collection - object proper

Re: Standard @iter module unfriendly to collection builders

On Nov 15, 2011, at 1:42 PM, Jason Orendorff wrote: > On Sun, Nov 13, 2011 at 12:17 PM, Erik Arvidsson > wrote: >> Another thing to consider is whether these functions belong in an iter >> module or in a reflect module? I'm leaning towards the letter. > > I completely agree. > > for-of should b

Re: The class operator: a bridge between object and function exemplers

On Nov 15, 2011, at 10:34 AM, Russell Leggett wrote: > Yes, of course you're right about that. There was something in the back of my > brain saying there might be a problem with that optimization, but I had hoped > it could be done, because that is probably the most common case. I suppose > yo

Re: The class operator: a bridge between object and function exemplers

On Nov 15, 2011, at 5:45 PM, Brendan Eich wrote: > On Nov 15, 2011, at 10:34 AM, Russell Leggett wrote: > >> Yes, of course you're right about that. There was something in the back of >> my brain saying there might be a problem with that optimization, but I had >> hoped it could be done, becau

Re: The class operator: a bridge between object and function exemplers

On Nov 15, 2011, at 4:08 PM, Russell Leggett wrote: > At this point, since it seems to me easy enough to implement as a function, > is there a reason to go all the way to an operator. I think if you include > the ability to have a declarative style with a name, then it pushes it over > the top

Wiki updates for String, Number and Math libraries

The Harmony proposals page contains several additions to the core String, Number and Math libraries, adding some of the most commonly created and requested helper operations to these libraries for ES6. I've uploaded to the wiki a first draft of candidate spec text for these library additions: *

Re: Function proxies without explicit construct trap

Earlier I wrote: All good points, and I don't recall any of them being intentional. Your > points seem to suggest changing the semantics such that calling "new > fproxy()" on a function proxy without a construct trap should perhaps just > simply throw a TypeError. Looking at the problem again, t

Alternative syntax for <|

Given the recent conversation about class as operator and its likely composition with <|, I propose turning the syntax: *MemberExpression* <| *ProtoLiteral* into extends *MemberExpression ProtoLiteral* In the common case of using the class operator, it would read much more naturally:

Re: Wiki updates for String, Number and Math libraries

Hi Luke, A few comments on the proposed String functions: 1) String.prototype.reverse(), as proposed, corrupts supplementary characters. Clause 6 of Ecma-262 redefines the word "character" as "a 16-bit unsigned value used to represent a single 16-bit unit of text", that is, a UTF-16 code unit.