On Wed, Mar 19, 2008 at 9:12 AM, Jonas Sicking <[EMAIL PROTECTED]> wrote:
>
>
> Travis Leithead wrote:
> > Since this spec is presumably creating a language binding for JavaScript,
> (and assuming interface objects are Functions, as seen by Opera), then why
> does:
> >
> > var div = new HTMLDivElement();
> >
> > produce a script error?
> >
> > Seems like a perfectly valid thing to do, essentially a shortcut to
> document.createElement('div')
>
> The problem is that this doesn't make sense for lots of interfaces. What
> does
>
> var a = new HTMLElement();
>
> do for example? And while there might only be one object that implement
> HTMLDivElement right now, who's to say that is true in the future.
>
> As it so happens there are actually at least 2 objects in firefox that
> implement that interface, a HTML <div> and an XHTML <div> (they differ
> in case sensitivity handling), which one should be instantiated by your
> code?
>
A Factory allows subclasses to define which classes to instantiate, as
Jonas mentioned. In this case: HTML document and XHTML document.
The design of a Factory method allows for implementation details for
complex operations (creating a SCRIPT or IMG, or
XXXTAG_NOT_IMPLEMENTED, or branches for categories of elements).
Creating a constructor would make browser implementation code a lot
more complicated, I imagine, though Jonas would know better than I do
about that.
Factory Method was a good choice over Constructor here.
Exposing a constructor of the same name as the interface - what,
besides compatibility problems, would that acheive?
The result would be exposed objects - Element - for example, that
might or might not create an element, depending on the browser. Each
javascript call to new Element would have to be wrapped in a
try-catch, as there is no way to determine if the object in question -
Element - implemented [[Construct]] and, currently, at least 3
browsers expose an object of a name corresponding to the interface and
none of them implement [[Construct]].
Garrett
> / Jonas
>
>
