On defining non-standard exotic objects

David Bruant bruant.d at gmail.com
Wed Jan 9 13:56:07 PST 2013

Le 09/01/2013 20:30, Allen Wirfs-Brock a écrit :
> 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.
I am indeed. When there is a spec, implementors "only" have to read it 
(and ask questions/submit test cases to whoever is writing the spec in 
case of doubts)

> 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.
It's also the most powerful available and by design, if I understand 
corretly, the most powerful that will ever be introduced to the 
ECMAScript language (for objects I mean).
We had data properties in ES3, we have getter/setters in ES5, we're 
about to get proxies in ES6 and I think that's where the trains stops 
for objects (maybe something will be introduced for document.all 
falsiness... maybe not? but that would be the actual last step)

> 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.
What I'm trying to get at is that these spec writers don't need to worry 
about the invariants if they define proxies. The invariants will take 
care of themselves.
If spec writers define proxies, by design, they won't be able to specify 
requirement that violate these 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".
The text no, but the coordination between different specs seems to 
indicate that there is a form of "moral authority" in what TC39 says. If 
in ES6 is written that any magic behavior has to fit in a proxy box, I 
think it will be read and understood.

> 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'm more worried of the case where spec writers do want to conform to 
the spec without necessarily having to understand every subtelty of the 
If they spec something as proxies, they can spec, prototype in code and 
see if it fits their intention or if they had missed something. This is 
not true for free-form objects.
As you say, writing "you have to use proxies" isn't that authoritative 
anyway, so it can just be written and those who feel expert enough can 
go on freeride.

> 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.


More information about the es-discuss mailing list