Here is a link to a documentatin for the weak map based solution that Kris
mentioned:
https://addons.mozilla.org/en-US/developers/docs/sdk/latest/modules/sdk/core/namespace.html
We find it invaluable and use for storing private field. Inheritance works,
but we did not found that feature all that
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
-discuss@mozilla.org
Subject: Re: WeakMap better than Private Symbols? (was: direct_proxies
problem)
On Thu, Jan 10, 2013 at 11:22 AM, Nathan Wall
nathan.w...@live.commailto:nathan.w...@live.com wrote:
// ES6 WeakMap
let timeMap = new WeakMap(),
// Store WeakMap methods to maintain
: WeakMap better than Private Symbols? (was: direct_proxies
problem)
On Thu, Jan 10, 2013 at 11:22 AM, Nathan Wall nathan.w...@live.com wrote:
// ES6 WeakMap
let timeMap = new WeakMap(),
// Store WeakMap methods to maintain integrity of the internal state
:* Re: WeakMap better than Private Symbols? (was: direct_proxies
problem)
On Thu, Jan 10, 2013 at 11:22 AM, Nathan Wall nathan.w...@live.comwrote:
// ES6 WeakMap
let timeMap = new WeakMap(),
// Store WeakMap methods to maintain integrity of the internal
state
@mozilla.org
*Subject:* Re: WeakMap better than Private Symbols? (was: direct_proxies
problem)
On Thu, Jan 10, 2013 at 11:22 AM, Nathan Wall nathan.w...@live.com
wrote:
// ES6 WeakMap
let timeMap = new WeakMap(),
// Store WeakMap methods to maintain integrity
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?
27 matches
Mail list logo
