Le 17/06/2011 02:38, Mark S. Miller a écrit :
On Thu, Jun 16, 2011 at 4:54 PM, David Bruant <[email protected]
<mailto:[email protected]>> 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.
Noted.
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.
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
