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.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
