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

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

From: Cameron McCormack <cam@mcc.id.au>
Date: Thu, 01 Sep 2011 16:14:28 +1200
Message-ID: <4E5F06A4.3010402@mcc.id.au>
To: "public-script-coord@w3.org" <public-script-coord@w3.org>
(Forgot to CC the list.)

-------- Original Message --------
Subject: Re: Microsoft Web IDL Last Call Comments (12-July-2011 edition)
Date: Mon, 29 Aug 2011 16:27:48 +1200
From: Cameron McCormack <cam@mcc.id.au>
To: Travis Leithead <Travis.Leithead@microsoft.com>

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.

to

   No extended attributes defined in this specification are applicable
   to X.

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

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

http://www.w3.org/mid/Pine.LNX.4.64.1107202125370.3775@ps20323.dreamhostps.com

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

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

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

OK.

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

> Section(s): 4.5.1.1, 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.

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

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

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

http://lists.w3.org/Archives/Public/public-script-coord/2011AprJun/0208.html

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?

> Typos______

Thanks, these all seem to have been fixed while addressing previous
comments.


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
#idl-operations:

   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.
Received on Thursday, 1 September 2011 04:14:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:04 UTC