July TC39 meeting notes, day 1
rossberg at google.com
Wed Aug 10 02:28:02 PDT 2011
On 9 August 2011 19:25, Kevin Reid <kpreid at google.com> wrote:
> On Tue, Aug 9, 2011 at 01:17, Andreas Rossberg <rossberg at google.com> wrote:
>> On 8 August 2011 18:46, Kevin Reid <kpreid at google.com> wrote:
>>> On Mon, Aug 8, 2011 at 08:50, Andreas Rossberg <rossberg at google.com> wrote:
>>>> Arguably, making a proxy trap return getters/setters seems a somewhat
>>>> pointless use case anyway. But nevertheless we need to have some
>>>> reasonable semantics for it.
>>> It allows a proxy to pretend to be an object which supports
>>> Object.defineOwnProperty normally.
>>> It allows a proxy to emulate, or wrap, an ordinary object which
>>> happens to have some accessor properties, while still being
>>> transparent to reflection (which I understand is one of the goals of
>>> the proxy facility).
>> Sure, but is that necessarily something that the _default_ traps have
>> to be able to mimic? There is no problem programming it up yourself if
>> you want it.
> Are you proposing a revised division of fundamental vs. derived traps?
> If not, what do you propose the default derived get or set trap do in
> the event that it gets an accessor property descriptor in response to
I guess my point was that there is no natural law demanding that the
default traps have "perfect" semantics. So we could e.g. pass null to
the accessors in that case. If you need a different semantics, program
it. I'm not necessarily proposing that path, just pointing out the
On the other hand, it is not at all necessary that we are able to
express the default traps as _closed_ JS functions. If the proxy
object is simply bound to a free variable in the get/set default code,
for example, I don't see that as a real problem. So that might be an
alternative solution as far as the spec is concerned (without
resorting to something more low-level).
Your argument against the latter kind of approach, as I understood it,
was that you as a programmer want to be able to simulate the _exact_
behaviour of the individual default traps in real code, _in
isolation_. I'm not sure why this has to be a goal. As you long as you
can simulate the overall behaviour easily, that seems good enough.
More information about the es-discuss