Function.prototype.bind and [[Construct]]

David-Sarah Hopwood david.hopwood at industrial-designers.co.uk
Sat Jan 17 19:47:32 PST 2009


Allen Wirfs-Brock wrote:
> The Kona minutes state "bind behavior: Should bind create only a call or
> both a call and a construct bound property? We decided to stick to last
> meeting's decision of creating both a call and a construct bound property.
[...]
> I was originally going to talk about various specification mechanism
> alternatives here,  but I now think it better to just enumerate the various
> possible user level meaning of bound constructors.
> 
> 1) bound functions do not have a "prototype" property, cannot be used as
>    constructors, and cannot be used with instanceOf.
> 2) bound functions do not have a "prototype", delegate to the target function
>    for construction and instanceOf using the target function's "prototype"
>    property.
> 3) bound functions have a "prototype" property whose value is bidirectionally
>    shared (in the arguments object sense) with the "prototype" property of
>    the target function.  Construction and instanceOf work using this shared
>    prototype value.
> 4) (current spec.) bound functions have a "prototype" that is initialized to
>    the value of the target function's "prototype" property.  Construction
>    uses the target "prototype" value, instanceOf uses the bound function's
>    "prototype" value.
> 5) bound functions have a "prototype" property that is initialized to the value
>    of the target function's "prototype" property.  However, both construction
>    and instanceOf use the target function's "prototype" value.
> 6) bound functions have a "prototype" property that is initialized to the value
>    of the target function's "prototype" property. Both construction and
>    instanceOf use the bound function's "prototype" value.

6a) bound functions have a "prototype" property that is initialized to
    the value of the target function's "prototype" property, and is
    non-[[Writable]] and non-[[Configurable]]. Both construction and
    instanceof use the bound function's "prototype" property.

> 7) Initially the bound function has a "prototype" whose value appears to be
>    unidirectionally shared with the target function and construction and
>    instanceOf use the target function's "prototype" value.  However, if the
>    bound function's "prototype" is explicitly set to some value, then
>    construction and instanceOf uses the bound function's "prototype" value.
>    Setting the bound function's "prototype" property does not change the
>    target function's "prototype" property.

7a) bound functions have a "prototype" property that unidirectionally and
    permanently reflects the current value of the target function's
    "prototype" property; attempting to set this property on the bound
    function throws an exception. (This would be specified using a
    non-[[Configurable]] accessor property where the setter throws an
    exception.)

6a) and 7a) seem preferable to me because I don't think it is necessary,
for the expected use cases of bound functions, that they should have a
modifiable "prototype" property. These options adequately support use of
a bound function as a constructor and with instanceof, but avoid any
confusion or unclear semantics resulting from being able to modify
the bound function's "prototype". They support chains of bound functions,
and bound functions sharing a target function, with obvious semantics,
and are both easily specifiable.

-- 
David-Sarah Hopwood ⚥



More information about the Es-discuss mailing list