[Harmony Proxies] Proposal: Property fixing

David Bruant david.bruant at labri.fr
Fri Jun 17 04:53:22 PDT 2011

Le 17/06/2011 02:38, Mark S. Miller a écrit :
> On Thu, Jun 16, 2011 at 4:54 PM, David Bruant <david.bruant at labri.fr 
> <mailto:david.bruant at labri.fr>> wrote:
>     I think that the deeper question we have to deal with now is the
>     exact semantics of configurability when it comes to "non-natural
>     objects" (array, host objects, proxies. Is there an official name
>     for them in the spec?).
> Allen and I just had a long phone conversation about these issues. We 
> ended up speaking in terms of a three part distinction:
> * normal native objects, i.e., those native objects or functions whose 
> internal methods operate in the normal non-magical way. Normal native 
> functions includes both built-in functions (e.g. 
> Object.prototype.valueOf) and functions written in JavaScript (e.g., 
> what "function(){}" evaluates to).
> * abnormal native objects, like arrays, whose internal methods are 
> still fully specified by the ES5 spec, but whose behavior is peculiar 
> / magical.
> * non-native objects, i.e., "host objects". We started our 
> conversation with a long digression into spec legalese about whether 
> an object could be neither native nor host. I still take the position 
> that there cannot be by definition. I don't know whether Allen ended 
> up agreeing. But we agreed that there are not currently any such 
> taxonomy breaking objects, and so for our purposes we could use 
> "non-native" and "host" as synonyms. "non-native" is less confusing 
> since it avoids tempting one into inventing a fourth category.
> In ES6, proxies create an open ended set of abnormal native objects 
> whose behavior is defined by JavaScript code. To ES5 code in an ES6 
> environment, such proxies are non-native, in that their ES5-level 
> behavior is not fully specified by the ES5 spec.

>     Currently, ES5 - 8.6.2 says:
>     "The [[GetOwnProperty]] internal method of a host object must
>     conform to the following invariants for each property of the host
>     object:
>     (...five bullets points...)"
>     I'd like to ask a few questions on this part of the spec:
>     Why are we expecting anything from host (all if including arrays?)
>     objects at all? (I know this one is naive and a bit provocative,
>     but I actually wonder)
> Because it's in the spec, and we should all ensure that any violations 
> of the spec stand out like a sore thumb in standard test suites.
>     Why are we expecting host (all if including arrays?) objects to
>     respect these particular invariants (this is actually 5 questions)
>     and no other?
> Because these invariants are in the spec.
> Put another way, do you expect Safari to eventually fix the December 
> "valueOf" bug they haven't yet even confirmed? Why?
> Should we ever stop expecting anyone to pay attention to the spec, I 
> suggest that TC39 disband.
> Another useful line of question is: Why are these invariants in the 
> spec? This is useful to discuss, but is a separate matter.
This is what I was asking, sorry for the confusion. Be sure that if I 
was ok with implementations not caring about the spec, I wouldn't have 
joined es-discuss and I wouldn't file bugs on test262 :-p If things are 
in the spec, they should be followed by implementations (and having 
implementors in the spec body certainly helps in that process even if 
it's apparently not entirely an easy battle).

However, my questions were the rationals of the spec. Why each of these 
5 bullets points is in the spec? What is the rational behind each of 
these? What discussion/arguments led to these particular invariants? Why 
no other invariant?

(I understand that the confusion may have come from the formulation of 
my questions. I asked "Why are /we/...". By "we", I meant "people who 
discuss the spec", and you apparently interpreted "implementors")

Sorry again for the confusion.

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

More information about the es-discuss mailing list