>> the challenge with creating a "normal constructor"
Forgive me if my language is imprecise, but the basic notion is that in
general one cannot create a constructor that creates a DOM node because
(most? all?) browsers make under the hood mappings to internal code (C++
for Blink and Webkit). For example, note that HTMLElement and descendents
are not callable from JS.
Erik Arvidsson came up with a strategy for overcoming this in Blink, but to
my recollection Boris Zbarsky said this was a non-starter in Gecko.
Because of this constraint Dimitri's current system involves supplying only
a prototype to the system, which hands you back a generated constructor.
Wrt 'has-a' and 'is-a', at one point I polyfilled a system where the user
object has-a Element instead of is-a Element. This gets around the
constructor problem, but has some drawbacks: e.g. users want custom API on
the node (at instance time we populated the node with public API, a
per-instance cost). The fatal problem was that utlimately users rejected
the separation between the true element and the code they wrote (which
boils down to 'this !== Element instance' in the custom code).
HTH,
Scott
On Sun, Apr 14, 2013 at 6:11 AM, Brian Kardell <bkardell@gmail.com> wrote:
> Can Scott or Daniel or someone explain the challenge with creating a
> "normal constructor" that has been mentioned a few times (Scott mentioned
> has-a). I get the feeling that several people are playing catch up on that
> challenge and the implications that are causing worry. Until people have
> some shared understanding it is difficult to impossible to reach something
> acceptable all around. Hard to solve the unknown problems.
>