The fact that you're dynamically changing the prototype as a part of this solution is a strong indicator that this usage of subclassing is somewhat questionable. I suspect that you'll find other gotachas with this approach.
I understand that the DOM is dealing with some design constraints that are less than ideal, but the only "right" ways to do this that I can think of at the moment are: - Swap out the element when the custom class is registered, as Allen suggested. - Use composition instead of subclassing to define custom behavior. On Wed, Jul 1, 2015 at 10:56 AM Allen Wirfs-Brock <al...@wirfs-brock.com> wrote: > > On Jun 30, 2015, at 8:31 PM, Domenic Denicola wrote: > > > From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com] > > > >> no, not in the way that I believe you intend > > > > Can you explain why? Is the design you and Kevin have been working on > based on lexical restrictions? > > No sure what you specifically mean. It requires that private slots be > declared as part of a class definitions so that the metadata need to > allocate them is available to the class constructor. > > > > > >> It isn't that subclass specific private state "initialization" must be > performed in the constructors. In the design that Kevin and I have been > working on, the total number of private state slots (and some meta data > for each one) must be knowable and fixed when an object is allocated (in > other words, private slots cannot be added to an object after it is > initially allocated). > > > > This seems like it then compares poorly with weak maps for private > state. It makes sense as a strong mode restriction, but not as a default > one... > > It is the "conventional model" of private state that is used by most > languages. It has lots of very desirable characteristics. And, it's hard > enough to insert one private state model into ES. We aren't going to end > up with more than one, at the language level. > > > > > Anyway, the design for upgradable custom elements is based around the > idea that subclasses would never need to customize the allocator, thus > allowing the UA to do their magical allocation of C++ HTMLElement stuff. If > private state requires customizing the allocator, I am not sure that custom > elements would be able to take advantage of it anyway... I suppose it > depends on the details of the proposal. > > > > This is model is, to a first approximation the C++ model and the also the > model the ES currently uses for built-ins so I don't expect that UA > allocators will have significant difficulties supporting it. > > Allen > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
