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

Re: [Constructor] and [NamedConstructor]

From: Alex Russell <slightlyoff@google.com>
Date: Mon, 22 Aug 2011 22:46:25 -0700
Message-ID: <CANr5HFXBMXuY+NWOvWPbt0gscDK20NqFqZYwhrrcca_wrkOqLQ@mail.gmail.com>
To: Cameron McCormack <cam@mcc.id.au>
Cc: David Flanagan <dflanagan@mozilla.com>, public-script-coord@w3.org
On Mon, Aug 22, 2011 at 8:31 PM, Cameron McCormack <cam@mcc.id.au> wrote:
> 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 { };
>  }

If this is the de-sugaring, it's pretty nasty. It'd be better if the
factory only acted as one in the absence of "new".

> ?  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 05:47:20 UTC

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