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

+1 more…

Title: Explicitly disallow passing optional parameters out of order


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:

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.

From: Travis Leithead
Sent: Friday, August 19, 2011 4:02 PM
To:; Cameron McCormack
Subject: Microsoft Web IDL Last Call Comments (12-July-2011 edition)

Unfortunately, I haven't cross-correlated this feedback with, so there may be dups.



Last Call Working Draft Specification Feedback July 12, 2011

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.

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

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

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.

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.

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.

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

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

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.

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

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 is a good behavior, which would remove the need for this above clause.

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.



Title: Text in **...** should be "size" not "length"

Description: Objects implementing OrderedMap support indexed properties with indices in the range 0 = index < OrderedMap::**length**.

Section(s): 3.4

Title: IDL Example text bad wording in **...**

Description: In an ECMAScript implementation of the IDL, **you an Object** can be passed in for the optional PaintOptions dictionary

Section(s): 4.3.9. [OverrideBuiltins]

Title: [OverrideBuiltins] section has bad wording in **...**

Description: If the [OverrideBuiltins] extended attribute appears on an interface, it indicates that for a platform object implementing the interface, properties will appear to **be own the object** corresponding to all of the object’s supported property names, regardless [...]


Title: Step 7.1.4 and step 8 of algorithm, "R" should be "candidates"


>>4.If there exists an entry in candidates with type list t where ti ∈ types, then remove from R all entries with type list t where ti ∉ types.

>>8.Return R.

The set R is never populated in this algorithm, I think this is a typo and you intended to use "candidates" but used R instead.

Received on Friday, 19 August 2011 23:10:38 UTC