[Bug 12248] Make objects first-class API citizens

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12248

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

Agreed.

> 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