Minimalist Classes

Axel Rauschmayer axel at rauschma.de
Tue Nov 1 11:58:52 PDT 2011


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 <axel at 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
axel at rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com



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


More information about the es-discuss mailing list