Will any new features be tied to constructors?
zenparsing at gmail.com
Wed Jul 1 15:21:37 UTC 2015
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
- Use composition instead of subclassing to define custom behavior.
On Wed, Jul 1, 2015 at 10:56 AM Allen Wirfs-Brock <allen at wirfs-brock.com>
> On Jun 30, 2015, at 8:31 PM, Domenic Denicola wrote:
> > From: Allen Wirfs-Brock [mailto:allen at 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss