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
<[email protected] <mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
