[Harmony Proxies] Proposal: Property fixing

Mark S. Miller erights at google.com
Thu Jun 16 17:38:41 PDT 2011


On Thu, Jun 16, 2011 at 4:54 PM, David Bruant <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.



> My understanding is that Allen seems to question the
> applicability/application/ground of the spec on that ("Those restriction had
> no teeth and it isn't clear that they have had any impact.").
>


*NOTE: I offer the following only as a concrete example of a more general
point, rather than to single out Safari. There are plenty of irritating spec
violations across all the major browsers. But the following is a
particularly clear example.*


Currently, on Safari WebKit Nightly Version 5.0.5 (5533.21.1, r88920) and on
Chrome 13.0.782.24 dev

    (1,{}.valueOf)()

evaluates to the global object, in violation of the ES5 spec. (This is fixed
as of Chrome 14.0.794.0 dev.) Although I reported <
https://bugs.webkit.org/show_bug.cgi?id=51097> in December 2010, WebKit
still lists this bug as UNCONFIRMED.

Possible conclusion from this: the ES5 spec has no teeth and it isn't clear
that it has any impact. My conclusion instead is that we're still in early
days at rolling specs into tests that pressure implementors to conform. But
when implementors violate clear spec language, we should report these
violations, ensure that these violations show up as violations in standard
test suites, and pressure implementors to eventually conform.




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



> David
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110616/3a8449fc/attachment-0001.html>


More information about the es-discuss mailing list