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
