On defining non-standard exotic objects

David Bruant 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
I disagree with this view for reasons Marc Stiegler expresses really 
well in his Lazy Programmer's Guide to Secure Computing talk [1].

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 [2] 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.

[1] http://www.youtube.com/watch?v=eL5o4PFuxTY
[2] https://github.com/tvcutsem/harmony-reflect/issues/11

More information about the es-discuss mailing list