> With your optional argument, I see a second solution that could be
> consistent. The prototype chain could contain the provided prototype
> then Function.prototype ("obj --> proto --> Function.prototype -->
> null" as opposed to your proposition which is: "obj --> proto --> null"
> ). Hence, there would be no need to enforce anything: instanceof would
> naturally find Function.prototype in the chain and function proxies
> would still be functions.
I don't quite see how that works; prototype inheritance is inherently
singly-linked. If the user specifies a prototype object, it already has its own
single prototype -- and we certainly aren't going to spec something that
*mutates* its existing prototype.
I suppose you could have some sort of multiple inheritance chain semantics that
says "follow this chain to the end, then when you're done, here's another
chain." But that seems kind of crazy.
You could spec something a bit more ad hoc, just for the purposes of
inheritance: that no matter what object the user provides, `instanceof' always
says true for Function.prototype as well. I don't have a concrete argument
against it, but it still looks funny to me.
The simple instanceof check seems simpler and reasonably intuitive.
> With your solution, by removing Function.prototype from the chain, proxy
> functions couldn't be .call()-ed or .apply()-ed
That's already true, even without my extension:
js> var proxy = Proxy.createFunction({}, function(){}, function(){})
js> proxy.call(this)
typein:11: TypeError: getPropertyDescriptor is not a function
Now, you can still do:
js> Function.prototype.call.call(proxy, this)
But that would continue to be true with my extension as well.
Dave
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
