[Bug 12248] Make objects first-class API citizens

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

--- Comment #16 from Brendan Eich <brendan@mozilla.org> 2011-03-08 03:50:55 UTC ---
(In reply to comment #14)
> (In reply to comment #13)
> > It's not a problem in practice for implementors or web
> > developers, so long as the [[Get]] internal operations used to access "keyword
> > parameters" are done before any other steps in the given method's spec, and in
> > a fixed order.
> 
> Just so that I am clear on the two choices here:
> 
> (A) if serializing, you would end up calling every getter on the object (and on
> all of the objects referenced by its properties, and so on) in a particular
> order, before actually doing the work in the method
> 
> (B) if not serializing, but handling accessors, the UA would just grab
> properties in whatever order it liked, at any time during the method


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?

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

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

No, see above.

> 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"?

> (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!

/be

-- 
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 03:50:58 UTC