Sorry, Jeremy, my comments were directed at Dmitry’s approach, not yours!
However, the call() problem is probably universally tricky, as you say. Another point to consider: What happens if there are several calls super.foo() and the last one makes a call this.foo() (infinite recursion can be prevented via a parameter) On Nov 1, 2011, at 19:48 , Jeremy Ashkenas wrote: > On Tue, Nov 1, 2011 at 2:21 PM, Axel Rauschmayer <a...@rauschma.de> wrote: > Invocation: B.describe.call(obj) should return "BA". With your library I > would expect it to return "BBA". > > Yes, it would. That's a good tricky case. I'm not sure if extra bookkeeping > could make sense of that call, as there isn't any information as to where the > function fits in to obj's prototype chain -- or if it's part of another > prototype chain entirely. I'd like to hope that something could be figured > out, but another alternative is for super() within a direct call() or apply() > to be an error. > > Would obj.one() work? As far as I can tell, your bookkeeping works for one > super recursion only, not for two. > > Yes, obj.one() would work. You can keep track of the super() depth > per-object-per-method ... and even for fancier cases where you restart the > same super() chain recursively from the outside. Imagine if one of the deeper > super.one()'s itself calls obj.one(), with a direct reference to the instance > (and a different parameter, to avoid infinite recursion). You can imagine > super counters as a stack instead of a value, and push a fresh one on, > popping it when the new obj.one() call exits. -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
