Le 31/08/2011 19:56, Michael Ficarra a écrit :
> This is my first reply on es-discuss, so my apologies if I've done
> something incorrectly and this doesn't get properly routed.
>
> David and Lasse, I'd like to direct you
> to https://github.com/kriskowal/es5-shim and, in particular, pull
> request #43: https://github.com/kriskowal/es5-shim/pull/43
>
> In that series of commits, I removed all runtime dependence on the
> environment and bootstrapped Function.prototype.bind while relying
> only on the existence of Function.prototype.call at definition time
> and with no dependencies at runtime. This allows me to call any
> function using `call(functionName, thisArg, argument0, argument1,
> ...)`. I also used that to bootsrap a similar `apply` function. The
> general idea behind bootstrapping a bind method was to make a sub-par
> `call` and `apply` implementation that relied on
> `Function.prototype.call.call`, but replacing them after defining bind
> by using our new bind method similarly to how you suggested. It'd
> probably be easier to just read the code, though, than have me
> continue trying to explain it.
So if I understand correctly, the relevant part of code to remove the
dependency to the runtime Function.prototype.call is the following:
-----
var nativeCall = Function.prototype.call;
var nativeApply = Function.prototype.apply;
nativeCall.call = nativeCall; // adding an own "call" property to the
native call

// assuming there is no native bind
var apply = function (fn, context, args) {
    return nativeCall.call(nativeApply, fn, context, args);
    },
     call = function (fn, context) {
    return apply(fn, context, nativeCall.call(nativeArraySlice,
arguments, 2));
    };

Function.prototype.bind = function bind(that){
  // no dependency on runtime Function.prototype.call
  // but dependency on runtime nativeCall.call
  // and dependency on runtime variable "call"
}

call = Function.prototype.bind.call(nativeCall, nativeCall);
apply = Function.prototype.bind.call(nativeCall, nativeApply);
-----
The idea of defining an own "call" property to nativeCall is
interesting, because it indeed allows to do nativeCall.call without
depending on redefinition of Function.prototype.call.
However, it only shifts the problem to the runtime value of
Function.prototype.call.call (all dots refer to an own property, even
the last one). In order to protect yourself from this dependency, you
could define nativeCall.call as non-writable and non-configurable (in
platforms allowing this).
Another idea would be to remove your dependency to nativeCall.call and
replace it with only "call" (which at the end is a new function which no
one should have access to unlike Function.prototype.call).

Regardless, the dance where you first define a call function, use it to
define Function.prototype.bind, use bind to redefine call to make it
independent of other things is a very interesting move!

Thanks,

David

>
> Michael Ficarra
>
>     ---------- Forwarded message ----------
>     From: David Bruant <david.bru...@labri.fr
>     <mailto:david.bru...@labri.fr>>
>     To: Lasse Reichstein <reichsteinatw...@gmail.com
>     <mailto:reichsteinatw...@gmail.com>>
>     Date: Wed, 31 Aug 2011 11:28:54 +0200
>     Subject: Re: Necessity of a syntax construct for bind
>     Le 31/08/2011 10:52, Lasse Reichstein a écrit :
>>
>>
>>     On Tue, Aug 30, 2011 at 11:46 PM, David Bruant
>>     <david.bru...@labri.fr <mailto:david.bru...@labri.fr>> wrote:
>>
>>         Le 30/08/2011 21:59, Lasse Reichstein a écrit :
>>>         A reliable .call could probably also achieve the same.
>>         A reliable .call could be achieved by composing a reliable
>>         .bind and the function call syntax.
>>
>>
>>     True. The Bind operation is the currying of the Call operation. 
>>
>>     Ah, that got me thinking. I can do
>>       var CallFunction =
>>     Function.prototype.call.bind(Function.prototype.call);
>>     since bind does give a different way to set the this-object for a
>>     call. This can be done once, before anybody gets to mangle the
>>     builtins, and can be stored for afterwards. Excellent!
>     Brilliant!
>
>     Of course, it requires a native Function.prototype.bind, but
>     that's brilliant!
>
>     David
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to