Suggestion: Proxy.[[GetOwnProperty]] caching non-configurable, non-writable data descriptors?

Alex Vincent ajvincent at gmail.com
Sat Oct 7 17:31:11 UTC 2017


> ---------- Forwarded message ----------
> From: Oriol _ <oriol-bugzilla at hotmail.com>
> Instead of storing the properties in a map, I think you could first call
> [[GetOwnProperty]] on the target, and if it's not configurable nor
> writable, return the same descriptor without calling the proxy trap.
>

I believe that's what my original suggestion was.

However, I disagree with this kind of things. Proxy traps are not only
> useful because of the value they return, they can also have desirable
> side-effects.
>
> --Oriol
>

You make an annoyingly good point here... :-) I made a similar point a few
months ago to someone who wanted to create a "hybrid" object which hid the
proxy as the prototype of a regular object, for speed.  *shudder*

That said, I still believe the algorithm I pointed out goes through a lot
of steps that *can* be unnecessary in the scenario I laid out... except
that the creator of the proxy has no way of telling the implementing engine
that.  There's no "proxy configuration options" that I can modify to pass
these optimizing hints to the engine.  Maybe *that's* something we might
need.

I know, this is quite a stretch, suggesting more API for proxies.  (I still
want Reflect.parse to happen, after all, and unlike kai zhu, I think
operator overloading is a good thing...)  I "blame" (actually, credit) Tom
van Cutsem for that, as he made a suggestion about optional properties
being an object in my own Membrane API recently.  It was a good idea there,
and for other algorithmic shortcuts in proxy traps, it might be a good idea
here.

I also take Caridy's point about Google Chrome 62's optimizations that are
coming.  I didn't know that was actually happening until Caridy posted
about it here.

Thanks for your response, though:  it's nice to know someone cares about
this.

Alex

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171007/85931d39/attachment.html>


More information about the es-discuss mailing list