On defining non-standard exotic objects

David Bruant bruant.d at gmail.com
Tue Jan 15 12:00:01 PST 2013

Le 15/01/2013 20:35, Tom Van Cutsem a écrit :
> 2013/1/9 David Bruant <bruant.d at gmail.com <mailto:bruant.d at gmail.com>>
>     Le 09/01/2013 20:30, Allen Wirfs-Brock a écrit :
>         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.
> Well, it's not that simple. Unfortunately direct proxies only enforce 
> the invariants using runtime checks, so it's easy to specify something 
> statically as a Proxy that will still fail at runtime.
> Of course testing helps here, but my point is that the Proxy API by 
> itself does not prevent broken invariants. One still needs a good 
> understanding of the invariants to define correct exotic objects.
I agree the static/runtime divide is not obvious, but as you say it's 
possible to test and I would add it's very cheap to test. Write the core 
of your function as JavaScript code, test against your favorite ES6 
implementation and if you misunderstood a part of the proxy API, you 
implementation and tests will tell you soon enough.

Describing in prose the invariant has its educational purpose, but I 
feel there is no loss and it's not that big of a burden in asking other 
specs to describe their magic in terms of the proxy API.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130115/8dd9ab7c/attachment.html>

More information about the es-discuss mailing list