>> 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 <bkard...@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. >