My ECMAScript 7 wishlist

Brendan Eich brendan at
Fri Sep 26 10:10:55 PDT 2014

Brendan Eich wrote:
> A general-purpose (as its name implies) nSP would hit lookup (get as 
> well as set) paths, not just mutation (set). But it seems Andreas's 
> "just to clear up some myths" words were missed, even considering only 
> mutation (not notification). 

 From private correspondence with Dean, it seems the cost of O.o (bad 
enough that the web platform cannot use it all over) may be assumed to 
be no better and not much worse than the cost of nSP. This isn't the 
case, nSP is strictly costlier and more complicated than O.o.

In JS, `set` applies after prototype chain walking (to find the setter, 
or the non-writable data property [in which case error], or to decide to 
make an own property on the directly referenced object). Call the proto 
walk step `lookup`.

`get` is more common than `set` but both require `lookup`, with differences.

O.o hits `set` but nSP hits `lookup` so affects both reading and writing.

A narrow throw-only nSP, say __throwOnNoSuchProperty__ with boolean 
value, would hit only the `get`-driven `lookup` paths. Still costlier in 
dynamic frequency and static code complexity than O.o, but much more 
targeted and (I think) optimizable. Need Andreas Rossberg and others to 
weigh in.

The "pay only if you use nSP or O.o" argument has limits. O.o got into 
Harmony on that basis, but then the myth that it was cheap enough to use 
all over the web platform grew -- bad myth, Andreas busted it.

A general nSP risks similar myth or hype-cycle and won't be optimized 
enough to "stick", any more than O.o will, per Andreas's final "Most of 
these costs are inherent to the mechanism, and there probably isn't much 
of a chance that they can be optimised by more than constant factors".

This implementation complexity and perf cost issue is not just about 
implementor burden. It changes naive user-(myth)understood economics and 
adds attractive nuisance risk. But just considering VM costs (code and 
runtime), it's a big deal.

A Proxy on a prototype chain, in contrast, modularizes the hit. It 
deoptimizes without multiplying `lookup` paths by two. The cost of host 
objects and proxies on prototypes has already been sunk, since you could 
make such chains even in 18 years ago.

I don't like it when implementor vs. user trade-offs fight in what seems 
like a zero-sum game. I'm Captain Kirk, I don't believe in the no-win 
scenario. (How'd that end? Ignore the retread/remake with role reversal!)

But in this case both implementors and users are facing physics. If the 
root post in this thread wants only an error for obj.typo, we shouldn't 
be chasing nSP, which is unstratified and over-general. We should try 
the proxy-in-library-clothing path and if it is too painful, consider 
some targeted and optimizable fix.


More information about the es-discuss mailing list