Catch-all proposal based on proxies

Mike Samuel mikesamuel at gmail.com
Sat Dec 12 10:53:28 PST 2009


2009/12/11 Mark S. Miller <erights at google.com>:
> On Fri, Dec 11, 2009 at 9:31 AM, Brendan Eich <brendan at mozilla.com> wrote:
>>
>> On Dec 11, 2009, at 8:36 AM, Maciej Stachowiak wrote:
>>
>>> On Dec 10, 2009, at 10:06 PM, Mark S. Miller wrote:
>>>
>>>> has 263. I will proceed to worry only about hasOwnProperty until someone
>>>> objects.
>>>
>>> Note that these are hits found in source repositories, not on the Web. So
>>> I would not put too much stock in the number of hits except as an existence
>>> proof. Both of these include hits from JavaScript libraries, likely meaning
>>> there are many deployed copies of the code in question (though unclear if
>>> that code path gets hit as the JS libraries are used in practice).
>>
>> Absolutely. The best case with codesearch would be to get no results --
>> that would suggest but not prove that the construct is not used. Getting any
>> hits casts doubt on claim that the construct isn't used enough to worry
>> about. More than a few handfuls of hits -> you should worry.
>>
>> Mark, I don't think we can pick meta-level methods to worry about and not
>> worry about, if the goal is transparent wrapping or catch-all based DOM
>> emulations. OTOH, propertyIsEnumerable is much less used than
>> hasOwnProperty, whether directly or via .call. But in principle it is the
>> same kind of animal.
>>
>
> I have now changed the spec so that Object.prototype.hasOwnProperty.call
> and Object.prototype. propertyIsEnumerable.call are base level rather than
> meta level methods. Proxies can now virtualize them fine, at the price of
> loading down the handler protocol with two more methods. As discussed
> earlier, I also added an invoke: trap so that named method invocations can
> be handled in one step without having to curry over the method name. So,
> altogether, three more methods. On the other hand, the double reflection
> needed by the membrane became simpler and faster, since the choke point is
> now an invoke trap.
> Of legacy methods, the only one which is still meta-level
> is Object.prototype.toString.call, as is necessary to preserve its meaning.
> The similar Function.prototype.toString.call remains in limbo awaiting a
> clearer spec. Neither of these should impede faithful emulation of existing
> DOM expectations.

On the interaction of Function.prototype.toString and function
proxies, one use case is code that tries to get at a function's name
as by doing

function nameOf(f) {
  if ('name' in f) { return f.name; }  // Works on some interpreters
  var m = ('' + f).match(/^function\s+([^(\s]+)/);
  return m ? m[1] : void 0;
}

I'm not sure how much of the existing code like this invokes toString
directly or indirectly instead of using Function.prototype.toString.

Function proxy handlers could implement has('name') then there might
not be a need for Function.prototype.toString to support this use
case.


> --
>    Cheers,
>    --MarkM
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


More information about the es-discuss mailing list