Fwd: RE: Microsoft Web IDL Last Call Comments (12-July-2011 edition)

(Forwarded with permission.)

-------- Original Message --------
Subject: RE: Microsoft Web IDL Last Call Comments (12-July-2011 edition)
Date: Thu, 8 Sep 2011 00:29:34 +0000
From: Travis Leithead <Travis.Leithead@microsoft.com>
To: Cameron McCormack <cam@mcc.id.au>

>-----Original Message-----
>From: Cameron McCormack [mailto:cam@mcc.id.au]
>Sent: Sunday, August 28, 2011 9:28 PM
>To: Travis Leithead
>Subject: Re: Microsoft Web IDL Last Call Comments (12-July-2011 edition)
>Hi Travis.
>Thanks for the review comments.  I'll reply inline with the resolution
>or discussion for each one below.  For the ones that have been resolved,
>can you please indicate whether the resolution is satisfactory.
>On 20/08/11 11:01 AM, Travis Leithead wrote:
>> Section(s): 3.5
>> Title: Contradiction in prose and example regarding extended attributes
>> applying to exception fields
>> Description: The text "No extended attributes are applicable to
>> exception fields" contradicts the previous example in the green box
>> which clearly shows extended attributes applying to the exception fields.
>When it's stated that certain extended attributes apply or not to
>particular IDL constructs, I really mean to limit that to the extended
>attributes defined in this specification.  The green box here is
>intended to show that syntactically, extended attributes can be used on
>exception fields.
>I have reworded sentences of the form
>   No extended attributes are applicable to X.
>   No extended attributes defined in this specification are applicable
>   to X.

This resolution is satisfactory.

>> Section(s): 3.8
>> Title: Clarify that user-objects can implement dictionary types
>> Description: The following paragraph should also mention that user
>> objects that implement a dictionary are acceptable when the expected
>> object of a particular interface is a dictionary type.
>> "When a user object is passed to a platform object expecting an object
>> of a particular interface, be it as an argument value in an operation
>> invocation, by assignment to an attribute, or through a dictionary
>> member, and that interface was not declared using the [Callback]extended
>> attribute, then the object will not be considered to be one that
>> implements that interface. Language bindings define precisely how this
>> check is made and what happens in response in such a case (such as
>> throwing an exception)."
>The platform/user object distinction is only intended to be for objects
>implementing interfaces, and dictionary types are not interfaces.
>Dictionary types in JS are represented by native objects, just like user
>objects implementing interfaces can be, but they are not user objects.
>I haven't made any change here.

OK. I see the difference--the key being the phrase "of a particular 
interface" which doesn't apply to dictionary types.

>> Section(s): 4.3.4
>> Title: Use cases for [CopyInheritedPrototype]
>> Description: Is there a use case, or specific W3C draft specification
>> that requires this functionality? As speced, the
>> [CopyInheritedPrototype] feature seems well-specified and we have no
>> objections to it. Our concern is that introducing ECMAScript binding
>> features in Web IDL for scenarios that are not required by another
>> specification will make it difficult to reliably test for interoperable
>> implementations as part of Web IDL's advancement toward Recommendation.
>> For example, I can see [Clamp] being used by the HTML Canvas 2D Context
>> specification to more accurately describe the behavior of
>> CanvasPixelArray's setter operation. However, I'm not sure what the use
>> case is for [CopyInheritedPrototype].
>I introduced it with http://www.w3.org/Bugs/Public/show_bug.cgi?id=10337
>but let's see what happens with the following thread where I have just
>stated now that maybe we should just remove it:

I will wait and see. Thanks for the pointer to the thread.

>> Section(s): 4.3.4, 4.5.3
>> Title: Confirmation of properties copied by [CopyInheritedPrototype]
>> Description: the spec says:
>>  >>Any properties corresponding to constants, attributes or operations
>> that are required to exist on an interface A’s interface prototype
>> objectMUST also exist, with the same characteristics, on the interface
>> prototype object of interfaces that inherit from A and are declared with
>> the [CopyInheritedPrototype]extended attribute.
>> ...will the copy of the inherited object's properties include the
>> supplemental and consequential interfaces of the inherited object as
>> well? Seems like it should but the above paragraph should be clear about
>> this if it does. Please confirm.
>I added a clarifying parenthetical
>   ...are required to existing on an interface A's interface prototype
>   object (whether due to interface members defined on A or on any of A's
>   consequential interfaces) MUST also exist...

This resolution is satisfactory.

>> Section(s): 4.3.11
>> Title: [Replaceable] paragraph uses the term "reconfigured" which
>> implies something other than intended
>> Description: In this paragraph:
>> "If the [Replaceable]extended attribute appears on a read onlyattribute,
>> it indicates that setting the corresponding property on the platform
>> object will result in that property being reconfigured to one that is
>> unrelated to the attribute, and which has the value being assigned."
>> We suggest using the term "shadowed" or "created" -- "reconfigured"
>> makes it sound like the original property is being configured (e.g.,
>> it's configurable: true, and it's being reconfigured to another type of
>> property), which is not consistent with section 4.5.5., which states
>> that a new property is created on the instance.
>Addressed this as part of timeless' omnibus comment LC-1.


>> Section(s): 4.3.15
>> Title: [Unforgeable] resilient to var creation?
>> Description: One of the problems we ran into during the creation of a
>> similar feature in IE9, was that users could simply create new vars of
>> [Unforgeable] attributes and the JS binding ran a different code path
>> for creating those than normal property assignments. This became a
>> problem because the "document" property was made [Unforgeable]--we
>> called it [msPreventRedeclaration]. Since the "document" accessor is
>> evaluated in terms of JavaScript global scope, it competed with
>> user-defined vars of the form:
>> var document = {};
>> At which point, the user-defined var would "shadow" the [Unforgeable]
>> attribute. To fix this, the Script engine had to be aware of the
>> [Unforgable] attribute and disallow var creation (at parse time). This
>> scenario, if ever one of the Window interface's properties were to be
>> made [Unforgeable] may be worth considering in the context of how this
>> binding is defined today.
>The spec says in #es-attributes that if an IDL attribute is
>[Unforgeable] that its property exists on the object itself as an own
>property, rather than on the interface prototype object.  I think this
>already addresses your concern, doesn't it?

Yes, since 1) the lookup for the property will always locate it on the 
object itself, and 2) the var declaration should fail when the property 
is configurable: false.

>> Section(s): 4.4
>> Title: namespace object properties should be enumerable
>> Description: The properties created for namespace objects act more like
>> IDL attributes (which are enumerable) than the standard properties
>> created for interface objects (which are not enumerable). Accordingly,
>> for both discoverability and consistency, the default [[Enumberable]]
>> value should be true instead of false:
>>  >> For every module that has a namespace object, a corresponding
>> property MUST exist on the relevant namespace object for the module. The
>> name of the property is the identifier of the module, its value is the
>> namespace object for the module, and the property has the attributes {
>> [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: true }.

This resolution is satisfactory.

>> Section(s): 4.5.1, 4.5.2
>> Title: Constructors and NamedConstructors should have a "prototype"
>> property {[[Value]], [[Writable]]:false, [[Enumerable]]:false,
>> [[Configurable]]:false}
>> Description: Web developers shouldn't have to care whether a given named
>> property for either a constructor (e.g., XMLHttpRequest), or a named
>> constructor (e.g., Image) are proper interface objects and thus have a
>> property to allow them to reference the interface prototype object. The
>> "prototype" property created for this purpose should refer to the
>> interface prototype object of the interface annotated with the
>> [Constructor] or [NamedConstructor] extended attributes. Note: that for
>> named constructors, this creates a asymetrical relationship between the
>> "prototype" property of the NamedConstructor property and the
>> "constructor" property of the interface prototype object. See IE9's
>> implementation where:
>> var x = new Image();
>> x.toString() == "[object HTMLImageElement]"
>Addressed this as part of David Flanagan's comment [LC-15].

This resolution is satisfactory.

>> Section(s):, 4.5.2
>> Title: should not allow call ambiguity in WebIDL's effective overload step
>>  >>6.If S contains more than one entry, then the constructor call is
>> ambiguous. Remove all but one entry from S according to rules specified
>> in the description of interfaceI, or arbitrarily if no such rules exist.
>> It should be a specification error if the API designer leaves ambiguity
>> in the overload set and does not specify how to resolve it in the
>> description of the interface. At this point in the algorithm, I think
>> it's fair to state that user agent behavior is undefined, and may
>> include selecting an arbitrary entry from S, but might also include
>> throwing a TypeError.
>OK, that is fair.  I just made it:
>   Remove all but one entry from S according to rules specified in the
>   description of interface I.  If these rules do not sufficiently
>   disambiguate the call, then the behavior of the function call
>   (including whether it selects a particular overload or simply throws
>   an exception) is undefined.

This resolution is satisfactory.

>> Section(s): 4.5.3, 4.9.2
>> Title: How are [exception] interface prototype objects referenced if
>> they are created from [NoInterfaceObject] interfaces?
>> Description: According to:
>>  >>There MUST exist an interface prototype object for every interface
>> defined, regardless of whether the interface was declared with the
>> [NoInterfaceObject]extended attribute. The interface prototype object
>> for a particular interface has properties that correspond to the
>> attributes and operations defined on that interface. These properties
>> are described in more detail in sections 4.5.5 and 4.5.6 below.
>> ...it appears that this is a requirement only for this spec's purposes
>> (for the purpose of collecting properties from supplemental and
>> consequential interfaces. Other than this algorithm binding detail, is
>> it possible from within the ECMAScript binding to obtain a reference to
>> an interface prototype object created as a result of a
>> [NoInterfaceObject] definition? If this is not possible, then our
>> recommendation is to make it more clear that this requirement is a
>> specification device, and remove the MUST requirement. If it is
>> possible, than a Note, or other clarification describing the rationale
>> for this statement would be appreciated.
>It is possible for interfaces that are used as non-supplemental
>interfaces, for example:
>   [NoInterfaceObject]
>   interface Foo {
>   };
>   partial interface Window {
>     attribute Foo foo;
>   };
>   Object.getPrototypeOf(window.foo);
>But if the interface is only ever used as a supplemental interface, then
>you would not be able to get access to its interface prototype object.
>I have added a note pointing this out.

That note is very helpful and clarified (a bit more--still a little 
fuzzy on "supplemental vs. consequential") the distinction for me.
This resolution is satisfactory.

>> Section(s): 4.7.1
>> Title: The section on "properties exposed before the prototype chain"
>> search shouldn't be needed.
>> Description: We believe that the behavior manifested by IE and as noted
>> in the bug http://www.w3.org/Bugs/Public/show_bug.cgi?id=8241 is a good
>> behavior, which would remove the need for this above clause.
>Acknowledged, I'll address this issue in the bug there.

This resolution is satisfactory.

>> Section(s): 4.7.2, 4.7.6
>> Title: Algorithms define named properties of an object to be enumerable
>> Description: The spec currently says in section 4.7.2:
>>  >>2.8. Set desc.[[Enumerable]] and desc.[[Configurable]] to true.
>> ...and in 4.7.6:
>>  >>2. If the object supports named properties, then the object’s
>> supported property names are enumerated next, in the order given in the
>> definition of the set of supported property names.
>> ...In most cases, the enumerability of named properties should _not_ be
>> enumerated (to match existing implementations). For example, this would
>> require enumerating all named properties on the Window object (e.g., all
>> elements with ID=xx would include XX in the window object enumeration).
>> This requirement to enumerate the named properties is only needed (as
>> far as I know) for the Storage interface, and might merit creation of a
>> new extended attribute [EnumerateNamedProperties] in order to override
>> the suggested default behavior.
>Here's the most recent discussion on enumerability of named properties:
>In the results you can see that for objects that have only indexed or
>only named properties, then they were enumerable, and that for objects
>with both indexed and named properties, there was inconsistency in terms
>of enumerability.  I preferred the solution of making them all
>enumerable because it's simple.
>Is there a problem with enumerating the (quirks-mode in some browsers)
>non-frame named properties on the Window object?  What about the ones
>for frames?

Apparently not, though IE9 may have different behavior in Quirks mode 
for enumeration, so I don't know whether there is a specific compat 
impact. In general, enumeration of the window is not a compatibility 
problem, since the enumeration includes user-defined names as well 
making is less useful as a list of potential operable items.

I sent my preference on this issue to the list.

>> Typos______
>Thanks, these all seem to have been fixed while addressing previous
>On 20/08/11 11:10 AM, Travis Leithead wrote:
>> Title: Explicitly disallow passing optional parameters out of order
>> Details:
>> Suppose I have a method as follows:
>>    void myFunc(optional int A, optional int B);
>> In ECMAScript, it is not possible for do something like myFunc(,2) and
>> have A be missing but supply a version for B=2. This is a feature of the
>> language and the language binding and not of WebIDL.
>> WebIDL should disallow being able to supply B not but A in any language
>> binding. Some languages, such as Visual Basic, have this capability. In
>> VB, I could write myFunc(B:=2) and this would supply just the value for B.
>> If a value is supplied for an optional argument, all optional arguments
>> to the left must also have a value supplied.
>> This is important for example with the WebSockets API’s close() method:
>> http://dev.w3.org/html5/websockets/#dom-websocket-close
>> Here the description talks about what to do if the second argument is
>> present and implicitly expects that if the second is present the first
>> must be.
>Agreed, this is a good point for bindings for languages that are more
>flexible with their optional arguments.  I added this text in
>   Web IDL operations do not support being called with omitted optional
>   arguments unless all subsequent optional arguments are also omitted.
>   Bindings for languages that do support function calling in this way
>   will fail such calls in a language binding specific manner.
>   Note: ECMAScript and Java, the two language for which bindings are
>   specified in this document, do not support function calling like
>   this.

This resolution is satisfactory.

Received on Thursday, 8 September 2011 23:29:29 UTC