Will any new features be tied to constructors?

Kevin Smith 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150701/fd5315eb/attachment.html>

More information about the es-discuss mailing list