W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2011

[Bug 12248] Make objects first-class API citizens

From: <bugzilla@jessica.w3.org>
Date: Tue, 08 Mar 2011 04:03:29 +0000
To: public-script-coord@w3.org
Message-Id: <E1Pwo8v-0005wv-6X@jessica.w3.org>

--- Comment #18 from Cameron McCormack <cam@mcc.id.au> 2011-03-08 04:03:28 UTC ---
(In reply to comment #16)
> We have mentioned ES5's ToPropertyDescriptor internal abstract operation here.
> It does (A). It "serializes" from a JS object into an internal data structure
> that is not visible to the programming language user.
> The objections I saw were:
> (1) What if the getter runs away?
> (2) What if the getter mutates relevant objects (including the "keyword
> parameter set" object)?
> The runaway or general availability property enforcement, we leave to quality
> of implementation.


> The getter mutating any object is a matter of the developer fouling its own
> nest. The native method spec won't have its integrity compromised since it will
> not sample any effects prematurely.
> > The former means spec writers don't need to think about when properties are
> > accessed (since Web IDL defines it), but can lead to wasted work (and side
> > effects!) calling getters for properties that the UA would never care about.
> Why is the method in question getting a property (remember, for an optional
> keyword parameter) whose value it does not use?

Well, not the *method* getting it, but the binding glue when marshalling
arguments from JS to the DOM implementation.

> > The latter means the UA can get away with less work, but spec writers need to
> > specify when and in what order properties would be accessed.  (And I think
> > there's a reasonable chance that not all spec writers will do this correctly.)
> (B) is a straw man. Neither Allen nor I have proposed it. We're agreeing on (A)
> with getters invoked. It seems Hixie does not agree.

Not a deliberate straw mind mind you.

> > I was saying "let's always do (A)", and you are saying "(B) is more natural". 
> No, see above.

Understood now.

> > Both options are well defined and could be interoperably implemented.  (Correct
> > me if I am wrong.)
> I don't think (B) is well-defined. "[W]hatever order it liked"?

Whatever order the specification defined.

> > (Option (B) also means that specification writers probably need to lower
> > themselves to talking about the ECMAScript binding specifically, rather than
> > whatever higher level IDL type this functionality would correspond to.)
> Option (B) is bogus. Let's get back to (A) since at least you, Allen, and I
> seem to agree on it!

I'm not sure we do agree on it. :-)

The generalized version of ToPropertyDescriptor that would be used here would
serialize the whole object graph starting from its argument.  (At least, that's
how I imagined the serialization to work.)  That could well result in getting a
property "whose value it [the method] does not use".

ToPropertyDescriptor itself doesn't look at properties other than "enumerable",
"configurable", etc.  My (A) would look at every property on the object (and
its objects (and its objects...)).

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Tuesday, 8 March 2011 04:03:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:02 UTC