r-proto-class

[Dmitry Soshnikov]

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 
>> <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
>

JFTR: It worked, now your code says: "you win". So, the hypothesis above 
is approved. https://gist.github.com/1367694

Anyway, that's said -- not for production sure, too much intermediate 
operations to keep the correct context in methods invocations.

Though, now I can almost (?) precisely say that even this issue with 
calling `this.move' with searching the `move' method no starting from 
the beginning but in place where we _currently_ are can also be solved 
via a simple library -- w/o help from lower level. So it's again the 
note that if the standard will provide such a sugar, it should make it 
much better -- in other case, why do we need it?

Dmitry.

>> 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/1f48de4f/attachment-0001.html>