Adding [[Invoke]] to address issues with methods called on Proxies

Tom Van Cutsem tomvc.be at gmail.com
Tue Jan 29 12:14:00 PST 2013


Hi,

2013/1/29 Brandon Benvie <brandon at brandonbenvie.com>

> Responding in this thread since it's a more appropriate place.
>
> 1.) It complicates the object model, in that it adds a new internal method
> to objects, but it also clarifies it. It falls under the same category as
> [[GetP]] and [[SetP]]: they complicate the object model, but they also
> clarify it and they are only observable to Proxies. All three are only
> observable to Proxies.
>

I disagree:

By calling Reflect.get(target, name, receiver) you can now call the
[[GetP]] internal method of a normal target object and provide your own
|this| binding, allowing you to properly forward property access when
target[name] is an accessor. No proxies in sight.


> Proxies are the thing that ultimately complicates the object model and
> these are fallout from it, but most of us agree that Proxies are worth it.
>

I think this is a strange way of characterizing proxies. The object model
is there, and proxies merely expose it to JS programmers. Proxies aren't
themselves supposed to complicate the object model further.

Of course, we had to do a lot of refactoring to the existing object model
(cf. the introduction of [[GetP]]/[[SetP]] because exposing the ES5.1
object model directly turned out to be painful (cf. the old
getPropertyDescriptor trap exposing [[GetProperty]]).

The introduction of [[Invoke]] would be a similar such refactoring. As you
note yourself: the idea of invoking a method is already present in the
spec, it's just not made explicit.

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130129/b2790edc/attachment.html>


More information about the es-discuss mailing list