For the record, there are no so-called private symbols. The concept being
referred to here is an implementation-only concept for naming an internal
property. These naming-things are never reified and available to JS code
and must not be.
On Thu, Jul 2, 2015 at 1:22 AM, Andreas Rossberg
wrote:
>
On 1 July 2015 at 17:12, Domenic Denicola 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 more part
>
> 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.
___
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 separately?
>
> 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
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
00:35
To: es-discuss@mozilla.org
Subject: Re: Will any new features be tied to constructors?
On 7/1/15 11:12 AM, Domenic Denicola wrote:
> Right now the UA allocators for all elements contains a single private slot,
> a pointer to the backing C++ object.
Just as a note, this is true conceptu
On 7/1/15 11:12 AM, Domenic Denicola wrote:
Right now the UA allocators for all elements contains a single private slot, a
pointer to the backing C++ object.
Just as a note, this is true conceptually in the specifications but
happens to not be true as a matter of implementation reality in eit
>
> ```js
> class Derived extends Base {
> constructor(...args) {
> super(a, b, c);
> doInitCode(this, ...args);
> }
> }
> ```
>
> via a function
>
> ```js
> function makeDerived(...args) {
> const o = Reflect.construct(Base, [a, b, c], Derived);
> doInitCode(o, ...args);
> return
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 ar
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 allo
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 specific
new more
> specific node that is an instance of the named subclass.
Anne explained this to you in
https://esdiscuss.org/topic/will-any-new-features-be-tied-to-constructors#content-3.
There's also the issue that replacing nodes that have children gets much more
complicated, especially if those nod
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 create
On Wed, Jul 1, 2015 at 3:49 PM, Domenic Denicola 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 else is ne
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 ar
On Wed, Jul 1, 2015 at 2:50 PM, Domenic Denicola 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 are normal
subc
>
> 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 bui
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
On Wed, Jul 1, 2015 at 10:56 AM, Domenic Denicola 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 if not being le
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:54 AM, Domenic Denicola 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 that Dmitry'
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 t
On Jun 30, 2015, at 5:54 PM, Domenic Denicola wrote:
> 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(..
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 w
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]();
}
}
```
then,
On Tue, Jun 30, 2015 at 6:41 PM, Kevin Smith 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 state "slots" ar
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
>
> 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 design
On Tue, Jun 30, 2015 at 5:54 PM, Allen Wirfs-Brock
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. It's explained in
On Jun 29, 2015, at 11:29 AM, Anne van Kesteren wrote:
> On Sat, Jun 27, 2015 at 2:21 AM, Anne van Kesteren 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. Th
On Sat, Jun 27, 2015 at 2:21 AM, Anne van Kesteren 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 script to load l
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 script to load lazily while the parser continues running.
However, if the user age
33 matches
Mail list logo
