On defining non-standard exotic objects
bruant.d at gmail.com
Wed Jan 9 06:07:26 PST 2013
Le 31/12/2012 13:43, Tom Van Cutsem a écrit :
> Hi David,
> I generally support this view, although it may be too restrictive to
> completely disallow non-standard exotics.
> Instead, I would be happy if we could just state that non-standard
> exotics are expected to uphold "the invariants of the ES6 object
> model", which will presumably be codified in Section 22.214.171.124.
I disagree with this view for reasons Marc Stiegler expresses really
well in his Lazy Programmer's Guide to Secure Computing talk .
The current situation is that ES folks would like to impose some
restrictions on how the language can be extended, especially when it
comes to objects. To the possible extent (and it looks possible), the
limits would be the one set by what's possible by proxies.
Now, there are 2 choices:
1) "do whatever you want within these boundaries defined in prose"
2) "proxies are the most powerful extension mechanism at your disposal"
The former requires people to read the spec carefully, become very
intimate with it. The recent issue you have solved  shows a very
subtle problem. I don't think non-standard exotic object spec writers
should be expected to understand all these subtleties. And I don't think
every subtlety can be documented in the spec. At every non-standard
exotic object spec change, people will have to re-review if all
properties are properly enforced.
The latter solution is the ocap-style lazy one (in Marc Stiegler's
sense). All properties that have been carefully weighted and crafted on
es-discuss will apply to non-ECMAScript standard objects. Spec writer
for these objects won't need to know the details. They just have to fit
in the box they are provided and subtleties are taken care of by the
box, by design of how the box is being designed.
One point I could understand is that maybe script proxies will not
necessarily make a conveninent box for spec writers. If this is really
an issue, ECMAScript could define an intermediate proxy representation
that would be used to spec proxies and by other spec writers. But I
think non-standard exotic objects spec writers could work easily with:
"object X is a proxy which target is a new Y object and the handler is a
frozen object which trap methods are [enumerate traps and their
behaviors, specifically mention absent trap and that's on purpose]"
Ps: "non-standard exotic objects" is way too long to type. I'll be
aliasing that to "host objects" from now on.
More information about the es-discuss