On defining non-standard exotic objects

Allen Wirfs-Brock allen at wirfs-brock.com
Wed Jan 9 11:30:58 PST 2013


I'm uncomfortable with the blurring of the boundary between specification and implementation that I see in this thread.

Proxy is the only "standard" extension mechanism provided by ES6 for defining non-standard exotic objects. If non-proxy based non-standard exotic objects exist within an implementation then they must be defined using some other extension mechanism that is inherently implementation dependent.  It is presumably also up to the implementation (or the host environment) to determine who has access to any such extension mechanism.  For example, such a mechanism might only be available to components that are statically linked with the implementation engine. 

Regardless of the interfacing mechanism used to define non-standard exotic objects, all exotic object are required by the standard to conform to the essential invariants that will be defined in section 8.1.6.1 (this section number will ultimately change).  An implementation specific extension mechanism might actively enforce those invariants, similarly to what the Proxy mechanism is specified to do.  Or, it might place that burden upon the component that is using the extension mechanism in which case any component that defines objects that violate the 8.1.6.1 invariants would have to be considered a buggy component just as would a component that violated any other interfacing rule of extension mechanism. 

David seems to be primarily concerned about people who are writing specs. for non-standard exotic objects (eg, W3C/WebIDL-based spec. writers)  rather than implementors of such objects.  In that case, it is probably reasonable for such a spec. writer to assume that the objects must be implementable using the Proxy mechanism.  After all, that is the only extension mechanism that is guaranteed to be available in a standards compliant ES6 implementation.  That still doesn't mean that such a spec. writer doesn't need to understand the ES object invariants as they shouldn't be writing any specification requirments that violates those invariants. However, it does mean that they should be able to test their specification by doing a Proxy-based prototype implementation.  I can even imagine that such a prototype implementation could be made a mandatory part of the spec. development process.

In the end, specifications don't have any enforcement power and perhaps not even all that much "moral authority".  If an implementation really needs to do something that is forbidden by a spec. it will do it anyway. Browser implementations and HTML5 certainly takes this perspective WRT Ecma-262 and re-specifies things such that don't match current browser requirements. 

I don't see any need for an intermediate proxy representation or for attempting to limit non-proxy based extension mechanisms.  However, if Proxy is not sufficiently powerful to support everything that needs to be done in the real world (and in particular by browsers) then we probably should be looking at how to fill those deficiencies. 

Allen




On Jan 9, 2013, at 6:07 AM, David Bruant wrote:

> 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 8.1.6.3.
> 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]"
> 
> David
> 
> 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
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 



More information about the es-discuss mailing list