dmitry.soshnikov at gmail.com
Tue Nov 15 09:33:01 PST 2011
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 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?
>> super is not a beast you can implement trivially in ES. I actually
>> have a stackoverflow question
>> 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.
>> On Tue, Nov 15, 2011 at 12:34 PM, Dmitry Soshnikov
>> <dmitry.soshnikov at gmail.com <mailto:dmitry.soshnikov at gmail.com>> wrote:
>> <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.
>> es-discuss mailing list
>> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss