On 1 July 2015 at 17:12, Domenic Denicola d...@domenic.me wrote:
Similarly, for several V8 built-ins, private state is not done via the
allocator at all, but instead via private symbols that act quite similar
to data properties. They can be added or removed at any time. In short,
they're much
From: Anne van Kesteren [mailto:ann...@annevk.nl]
I don't see how this matters given that Dmitry's design depends on not
executing JavaScript while constructing the element. Whereas if you put
this[Element.init]() in the constructor it totally would.
Dmitry's design does *not* depend on
On Wed, Jul 1, 2015 at 2:50 PM, Domenic Denicola d...@domenic.me wrote:
I.e., do you see any plausible world in which you're allowed to create a
custom element with a custom allocator, instead of the browser-supplied
HTMLElement one?
I'm not sure I follow. In a world where custom elements
From: Anne van Kesteren [mailto:ann...@annevk.nl]
In a world where custom elements are normal subclassed objects, they would
just call super() from the constructor to set the browser-supplied bits and
then add whatever else is needed themselves.
Yes, that is the Dmitry proposal.
Or are
From: Anne van Kesteren [mailto:ann...@annevk.nl]
Fair, but it does depend on that not always being invoked at the same time as
the constructor. So even if not being lexically part of the constructor was
fine, you could still not depend on it being invoked at the same time.
Yeah, you're
The essence of Dmitry's design is to disallow custom allocation, while
allowing custom initialization. This allows you to optionally decouple the
two stages when necessary (upgrades, cloning, etc.) while also getting the
goodness where author code doing `new MyElement(...)` calls both
On Wed, Jul 1, 2015 at 3:49 PM, Domenic Denicola d...@domenic.me wrote:
From: Anne van Kesteren [mailto:ann...@annevk.nl]
In a world where custom elements are normal subclassed objects, they would
just call super() from the constructor to set the browser-supplied bits and
then add whatever
On Wed, Jul 1, 2015 at 10:56 AM, Domenic Denicola d...@domenic.me wrote:
Dmitry's design does *not* depend on that. In fact Dmitry's design includes
this[Element.init]() in the constructor.
Fair, but it does depend on that not always being invoked at the same
time as the constructor. So even
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
From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com]
Do one has yet explained to me, what is wrong with simply initially
inserting a dummy (generic) custom element node during DOM parsing and latter
(after the required JS code has loaded) replacing that node with a new more
specific
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
From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com]
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.
Really?
Right now the UA
On Jun 30, 2015, at 5:57 PM, Domenic Denicola wrote:
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of C.
Scott Ananian
But the design might work well as a proxy object? It could delegate to the
real object, with its private slots, after that object is created.
We
On Wed, Jul 1, 2015 at 2:54 AM, Domenic Denicola d...@domenic.me wrote:
Stated another way, which might be a bit stronger: will it be *lexically*
required that private state initialization be within the constructor, or will
it only be *temporally* required?
I don't see how this matters given
On 7/1/15 11:39 PM, Domenic Denicola wrote:
but upon re-reading that I see that I missed the at least in at least one
reserved slot
Yeah, it's hiding in there pretty well. ;)
I actually do have a related question, though. In the private state
proposals we're talking about, how would it be
On 7/2/15 12:18 AM, Kevin Smith wrote:
I actually do have a related question, though. In the private state
proposals we're talking about, how would it be observable whether the
private slots the class defines are in fact allocated as part of the
object's allocation or
Thanks for the corrections Boris. I was basing what I said on a half-remembered
version of
https://ask.mozilla.org/question/850/how-do-webidl-methodsgetterssetters-tell-whether-objects-are-of-the-right-types/,
but upon re-reading that I see that I missed the at least in at least one
reserved
I actually do have a related question, though. In the private state
proposals we're talking about, how would it be observable whether the
private slots the class defines are in fact allocated as part of the
object's allocation or separately?
Not sure I understand the question. If the
Ah, I see. So what's observable is not whether things are a contiguous
chunk of memory or whatnot but rather whether the slots exist. And a
proposed invariant is that the slots, once observed to exist or not
cannot change that state. Is my understanding correct now?
Yes.
Allen, Kevin: I think the key question about private state and how it interacts
with Anne's question is this.
Given a base class looking roughly like
```js
class HTMLElement extends Element {
constructor(...) {
super(...);
// ...other stuff...
this[Element.init]();
}
}
```
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of C. Scott
Ananian
But the design might work well as a proxy object? It could delegate to the
real object, with its private slots, after that object is created.
We briefly discussed this with the V8 team. Their opinion was
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?
It isn't that subclass specific private state initialization must be
performed in the
On Jun 29, 2015, at 11:29 AM, Anne van Kesteren wrote:
On Sat, Jun 27, 2015 at 2:21 AM, Anne van Kesteren ann...@annevk.nl wrote:
For custom elements in DOM there's a proposal to have the constructor
be controlled by the user agent and have some kind of callback that
actually initiates the
But the design might work well as a proxy object? It could delegate
to the real object, with its private slots, after that object is
created.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Tue, Jun 30, 2015 at 5:54 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
How would your hypothetical early allocated objects be observably exposed?
The design is basically that the browser first creates a normal
element, and at a later point changes the prototype and invokes the
callback.
The design is basically that the browser first creates a normal
element, and at a later point changes the prototype and invokes the
callback.
Changes the prototype dynamically? We're generally moving away from such
shenanigans.
That would indeed interact poorly with some of the designs for
On Tue, Jun 30, 2015 at 6:41 PM, Kevin Smith zenpars...@gmail.com wrote:
Changes the prototype dynamically? We're generally moving away from such
shenanigans.
That would indeed interact poorly with some of the designs for private state
that we've been entertaining. In such a scheme private
On Sat, Jun 27, 2015 at 2:21 AM, Anne van Kesteren ann...@annevk.nl wrote:
For custom elements in DOM there's a proposal to have the constructor
be controlled by the user agent and have some kind of callback that
actually initiates the element. This has some advantage in that it
allows the
28 matches
Mail list logo
