Le 09/01/2013 23:57, Andrea Giammarchi a écrit :
do you have any example of what you are saying? all my examples fail
and I don't understand other use cases.
I don't. You seem to be relying a lot on the Firefox implementation, but
there are 2 things to be aware of as far as I know (sorry I
Just to return back on the initial question:
The event stuff is a distraction and was merely to illustrate. See
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20158#c1 For the APIs
we define in DOM-land we aim to have them fully deterministic even
when developers do strange things.
Why not
On Thu, Jan 10, 2013 at 12:47 PM, François REMY
francois.remy@outlook.com wrote:
Why not order the keys alphabetically when you use them in a DOM API?
We could, however if iteration order is eventually defined it would be
kind of annoying if we sorted things.
--
http://annevankesteren.nl/
We could, however if iteration order is eventually defined it would be
kind of annoying if we sorted things.
Even if iteration order is going to be defined in some way, I doubt it will be
intuitive in any way. But I could be wrong, this is just a personal belief.
On Thu, Jan 10, 2013 at 1:22 PM, François REMY
francois.remy@outlook.com wrote:
Even if iteration order is going to be defined in some way, I doubt it will
be intuitive in any way. But I could be wrong, this is just a personal belief.
Based on what? The iteration order of keys that are
Choosing symbols or a weakmap would make a huge difference in how proxy
replacement would react to DOM algorithms.
If the DOM in terms of accessing private properties, then proxies can
replace DOM objects transparently. Their unknownPrivateSymbol trap
will be called [2] and if they don't
Nathan Wall wrote:
// ES6 Symbols
// Forgive me for not knowing what the current
// correct syntax is for creating a symbol:
let timestamp = new Symbol();
class SimpleDate {
construct(time) {
this.setTime(time);
}
Le 10/01/2013 17:22, Nathan Wall a écrit :
Choosing symbols or a weakmap would make a huge difference in how proxy
replacement would react to DOM algorithms.
If the DOM in terms of accessing private properties, then proxies can
replace DOM objects transparently. Their unknownPrivateSymbol trap
Nathan Wall wrote:
In the case of (1), the implementation using a private symbol will have
internal accesses to the `timestamp` symbol exposed through the
unknownPrivateSymbol trap.
Private symbols do not trap.
In the case of (2), the implementation using a private symbol will fail on a
Le 10/01/2013 17:41, Brendan Eich a écrit :
Nathan Wall wrote:
In the case of (1), the implementation using a private symbol will
have internal accesses to the `timestamp` symbol exposed through the
unknownPrivateSymbol trap.
Private symbols do not trap.
They do trap, but they don't leak.
At the very least, WeakMaps are potentially usable today (depending on the
target audience) while symbols are nowhere in sight. I’ve gotten a lot of
mileage out of this function, which as you said provides a similar
effective result as symbols (they differ in that the WeakMap version isn’t
It's funny: I've been considering a similar thread, but the opposite. I.e.
private symbols better than weak maps?
In particular, given the freezing clarification, the use cases for weak maps
instead of private symbols seem to reduce to adding *new* symbols to
extension-prevented objects.
Is
They both have their place since there's many uses for both inherited and
non-inherited private values.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Allen rightly has pointed out several times on es-discuss that WeakMaps
require GC special handling and are costly, compared to private symbols.
This is true not only for GC time, but especially for get/set runtime.
Properties named by Symbols, when implemented, should have the same
They both have their place since there's many uses for both inherited and
non-inherited private values.
Can we see some demonstrated use-cases for which WeakMaps are insufficient,
and private properties are? I continue to hear that private symbols are a
great idea without any discussion of
Private symbols should be faster. No need for hashing and GC of an object
with private symbols is the exact same GC as any other object. Getting the
GC behavior of a WeakMap is a lot harder (and thus slower).
...also what Brendan just said.
On Thu, Jan 10, 2013 at 11:50 AM, Brandon Benvie
On Thu, Jan 10, 2013 at 11:55 AM, Kevin Smith khs4...@gmail.com wrote:
They both have their place since there's many uses for both inherited and
non-inherited private values.
Can we see some demonstrated use-cases for which WeakMaps are
insufficient, and private properties are? I continue
From: Brandon Benvie [bran...@brandonbenvie.com]
Sent: Thursday, January 10, 2013 11:50
They both have their place since there's many uses for both inherited and
non-inherited private values.
Of course, (non-)inheritance is a great point.
Amusingly, using conventional OO terminology, it
Symbols (private or public, don't forget the latter) are crucial to ES6
and not going away :-|.
Besides the property access and GC costs of WeakMaps (which are probably
fine, but at least inevitable, when you really do need a WeakMap),
symbols allow coordination between friendly objects by
Domenic Denicola wrote:
From: Brandon Benvie [bran...@brandonbenvie.com]
Sent: Thursday, January 10, 2013 11:50
They both have their place since there's many uses for both inherited and
non-inherited private values.
Of course, (non-)inheritance is a great point.
Amusingly, using
Brendan Eich wrote:
Nathan Wall wrote:
In the case of (2), the implementation using a private symbol will fail on
a call to `setTime` when the object is frozen (I think).
Nope, we agreed that frozen objects support setting pre-existing (added
before the object was made non-extensible)
Nathan Wall wrote:
Brendan Eich wrote:
Nathan Wall wrote:
In the case of (2), the implementation using a private symbol will fail on a
call to `setTime` when the object is frozen (I think).
Nope, we agreed that frozen objects support setting pre-existing (added
before the object was made
As an aside, Irakli Gozashvili and I independently realized that you
could use a WeakMap for parallel objects with inheritance. Very
similar to Brendan’s createStorage, we put together a parallel
universe constructor.
function Parallel(root) {
var parallel = new WeakMap();
root = root ||
Brendan Eich:
No, not if the symbol is not in the whitelist. Zero information leak is
required.
That's good news too. Objection withdrawn. I guess I didn't correctly
understand David's point in the direct_proxies thread then :-/. I'll have to
reread it more carefully.
Thanks for the
On Jan 10, 2013, at 8:41 AM, Brendan Eich wrote:
Nathan Wall wrote:
In the case of (1), the implementation using a private symbol will have
internal accesses to the `timestamp` symbol exposed through the
unknownPrivateSymbol trap.
Private symbols do not trap.
In the case of (2), the
Brendan Eich:
No, not if the symbol is not in the whitelist. Zero information leak is
required.
That's good news too. Objection withdrawn.
Maybe I gave up too easy :). Is the `unknownPrivateSymbol` trap called? What's
the rationale for this trap?
Symbols (private or public, don't forget the latter) are crucial to ES6
and not going away :-|.
No problem here with public symbols! They provide collision-free property
naming without changing the underlying object model. Woot!
But when I ask for use cases for private symbols, I get
Really?? http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.15.5
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Rick Waldron [waldron.r...@gmail.com]
Sent: Thursday, January 10, 2013 14:57
To: Nathan Wall
Cc:
Right, that's not how the spec. is written.
You certainly could do that on a per instance basis by copying down the
methods. Perhaps even define yourself a subclass to do so. But it would be
silly to force this on every instance.
On Jan 10, 2013, at 12:04 PM, Domenic Denicola wrote:
On Thu, Jan 10, 2013 at 3:04 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Really?? http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.15.5
Wow, yep. For some reason, when I saw that example, I only recalled the
original WeakMap proposal—which is 2 years out of date. VERY
On Thu, Jan 10, 2013 at 3:14 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
Right, that's not how the spec. is written.
You certainly could do that on a per instance basis by copying down the
methods. Perhaps even define yourself a subclass to do so. But it would
be silly to force this
Nathan Wall wrote:
Brendan Eich:
No, not if the symbol is not in the whitelist. Zero information leak is
required.
That's good news too. Objection withdrawn.
Maybe I gave up too easy :). Is the `unknownPrivateSymbol` trap called? What's
the rationale for this trap?
[Cc'ing Tom and Mark to be sure there is agreement on what I'm claiming
in this message]
Le 10/01/2013 22:10, Brendan Eich a écrit :
Nathan Wall wrote:
Brendan Eich:
No, not if the symbol is not in the whitelist. Zero information
leak is
required.
That's good news too. Objection withdrawn.
On Thu, Jan 10, 2013 at 1:24 PM, David Bruant bruan...@gmail.com wrote:
I think the return true/false protocol should be replaced by a return/throw
protocol (return value is ignored). It'd be much more explicit this way.
FWIW, I kinda like the aesthetics of return/throw a bit better too,
David Bruant wrote:
[Cc'ing Tom and Mark to be sure there is agreement on what I'm
claiming in this message]
Le 10/01/2013 22:10, Brendan Eich a écrit :
Nathan Wall wrote:
Brendan Eich:
No, not if the symbol is not in the whitelist. Zero information
leak is
required.
That's good news too.
Le 10/01/2013 22:31, Tab Atkins Jr. a écrit :
On Thu, Jan 10, 2013 at 1:24 PM, David Bruant bruan...@gmail.com wrote:
I think the return true/false protocol should be replaced by a return/throw
protocol (return value is ignored). It'd be much more explicit this way.
FWIW, I kinda like the
David Bruant wrote:
For the long term, I expected DOM objects could be proxified.
Boris convinced me otherwise for DOM Nodes at least.
Are you so convinced that the `unknownPrivateSymbol` trap is necessary?
It's been decided early that a Proxy.isProxy method should be avoided,
because
function isNodeProxy(node) {
try {
return node instanceof Node
document.body.appendChild(node)
!!document.body.removeChild(node);
} catch(x) {
return false;
}
}
Excuse me, I got the logic wrong:
Jason Orendorff wrote:
On Tue, Jan 8, 2013 at 11:54 PM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
Boris and I talked more 1:1 -- it is not clear when a direct proxy
can be safely cast to its target. The internal proxies Gecko
uses are known implementations
39 matches
Mail list logo
