r-proto-class

[Dmitry Soshnikov]

On 15.11.2011 17:34, Jake Verbaten wrote:
> You fell for the broken super implementation trap 
> <http://jsfiddle.net/Wtx3E/1/>
>
> 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 super class will invoke the method of the sub class rather then 
> the method of the class itself.
>

I know perfectly this case. And yes, w/o caring additional info in the 
context, that a method is called as a result of `super', you can't 
determine correct value of `this' -- _regardless_ whether you hardcode 
names of classes or not.

OTOH, hypothetically, I can even imagine of of the solutions (though, of 
course again it's not for production, but as an experiment) -- to wrap 
every method with prologue that checks: if currently we are in a 
super-call, then get the prototype to which the method belongs 
(depending on the info from the super call):

this.move is transformed into:

if (this.__currentlyInSuper__) ... // take from parent proto
else return this.move(...) // take original

> super is not a beast you can implement trivially in ES. I actually 
> have a stackoverflow question 
> <http://stackoverflow.com/questions/8032566/emulate-super-in-javascript> 
> about super.
>

Thanks, I also answer JS-questions (for the case) ;)

> You can't actually implement super without hard coupling a reference 
> between Parent and Child. inheriting a generic super method from a 
> prototype won't work as far as I know.
>

Yep, it's hard, but seems possible (taking into account the idea 
described above).

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 even more important -- to be _really_ a sugar, but not 
syntactically odd stuff.

Dmitry.

> On Tue, Nov 15, 2011 at 12:34 PM, Dmitry Soshnikov 
> <dmitry.soshnikov at gmail.com <mailto:dmitry.soshnikov at gmail.com>> wrote:
>
>     Hi,
>
>     <Just on the Rights of a bike-shedding :)>
>
>     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 part of this lib
>     variant) -- at user-level a programmer uses native Object.create
>
>      * Class.new is a wrapper over Class.allocate and
>     Class.initialize. I.e. overriding <UserClass>.allocate you may
>     allocate different objects
>
>     It's just a lib, it's not proposed for standardization (you may
>     even not to comment on this letter, just take a look for a
>     curiosity); it's just shown again, that in both ES3 and ES5 we had
>     and have lib-versions of such sugar, including good class-level
>     super-calls. So again, if to talk about standardization, then the
>     standardized version (whichever it will be) should be at _least_
>     much better than all these libs. Including syntactically.
>
>     Cheers,
>     Dmitry.
>     _______________________________________________
>     es-discuss mailing list
>     es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>     https://mail.mozilla.org/listinfo/es-discuss
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111115/48991999/attachment.html>