Re: [Constructor] and [NamedConstructor]

Hi David.

Thanks for your comments.

On 29/07/11 11:05 AM, David Flanagan wrote:
> I've got the following comments on the LC draft (prompted by Alex
> Russell's recent email):
>
> 1) In §4.3.5 and §4.3.6 it might be helpful to add a note pointing out
> that these attributes create factory functions rather than true
> constructors, and that it is unnecessary and potentially inefficient to
> use the new keyword with them. (Or perhaps the notes should go in
> §4.5.1.1 and §4.5.2 instead)

Does that mean you consider this native JS function not to be a "true 
constructor":

   function F() {
     return { };
   }

?  Although with some implementations it might be less efficient to use 
new to invoke these constructors, I don't think it's going to be 
significant.  Implementations could well optimise these cases anyway. 
I'm not sure these notes would be useful.

> 2) Step 5 in §4.5.2 defines t<sub>0</sub> through t<sub>n-1</sub>, but
> then they are never used in the algorithm. I suspect that step 6 should
> change "to an IDL value" to "to an IDL value of type t<sub>i</sub>".

Agreed.

> 3) §4.5.2 doesn't say anything about the prototype property of a named
> constructor function. Shouldn't it have one, and shouldn't it have the
> same value as the prototype property of the interface object? (Note that
> FF and Chrome do not do this for Image(), but Safari does)

Safari/IEPP: Image.prototype == HTMLImageElement.prototype
Chrome: Image.prototype.[[Prototype]] == HTMLImageElement
Firefox: Image.prototype.[[Prototype]] == HTMLElement.prototype
Opera: Image.prototype === undefined

I agree, the Safari/IE behaviour makes most sense to me.

Here's the change:

http://dev.w3.org/cvsweb/2006/webapi/WebIDL/Overview.html.diff?r1=1.350;r2=1.351;f=h

Could you please indicate whether this resolution is acceptable.

Thanks,

Cameron

Received on Tuesday, 23 August 2011 03:31:41 UTC