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

Re: Non-constructible constructors and Arrays

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Fri, 9 Sep 2011 11:45:52 -0700
Message-ID: <CABZUbM06Z1FN2JHKAcnRbnogWOEy0RxmwO7NwThhThS_aLYjPQ@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Alex Russell <slightlyoff@google.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On 9/9/11, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 9/9/11 4:24 AM, Alex Russell wrote:
>>>   Specification writers need to write the actual behaviour for these
>>> constructors whether they are implicitly declared or not.
>>
>> The default behavior would simply be to generate objects of those
>> types without side effects.
>
> What if there are not normally objects of those types?  Or more than one
> kind of object of those types?
>
> For example, what should |new Element()| do if the specification doesn't
> define it?
Yes, I already asked.

   There's no sane behavior, because you have no idea what tag
> name to give it.
>
Possibly HTMLUnknownElement, though I can't see a reason for why
anybody would want such shortcut behavior from `new Element`.

Factories are justified in DOM core by their trait of extensibility:
"...DOM APIs to be implemented as a thin veneer on top of legacy
applications with their own data structures, or on top of newer
applications with different class hierarchies. This also means that
ordinary constructors (in the Java or C++ sense) cannot be used to
create DOM objects, since the underlying objects to be constructed may
have little relationship to the DOM interfaces..."

-http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-249F15BA

> You can find some examples where the behavior is "clear"... But even in
> the |new HTMLDivElement| case, what would define what the ownerDocument
> of the new element is?  WebIDL itself certainly can't make such a
> definition.  The fact that an ownerDocument even exists is specific to
> the HTMLDivElement interface, and whatever spec defines that interface
> would need to explicitly address that.
>
The global object's window's document -- window.document, e.g. in
newer browsers:

  new Image().ownerDocument == window.document

<aside title="[[Construct]] is Not Always Available">
>> In any case, it repairs the mental model of the mappings between JS
>> and DOM where in JS, functions can *always* be invoked via "new",
>
Only functions which implement [[Construct]] can be invoked using `new`.

ECMA-262 specification explicitly states that the built-in functions
don't implement [[Construct]]. Try a `new parseInt` for example. It
might work in some Moz engines, but it can be expected to throw -- and
throw it will in IE.
</aside>

Not sure how that matters, just correcting the facts.

The properties of an in a document in a version of a browser may be
unique to that environment. A different way of thinking instead of
categorizing objects by their tagName is to consider which interfaces
those objects support. IOW, not "is it constructed by [x]", but "can
it do [x]".
-- 
Garrett
Received on Friday, 9 September 2011 18:46:20 UTC

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