Le 22/01/2013 07:31, Benoit Marchant a écrit :
Why can we express in a property descriptor the notion of writable,
configurable or enumerable but not private?
Because strings are forgeable, meaning that someone you may not trust
can read in your code or guess (maybe with low probability) the
On Mon, Jan 21, 2013 at 6:04 AM, David Bruant bruan...@gmail.com wrote:
[...] WeakMap.prototype.clear questions the property that was true before
its adoption (you can only modify a weakmap entry if you have the key)
David, would you please elaborate your argument for this invariant? This
the
Le 22/01/2013 11:47, Jason Orendorff a écrit :
On Mon, Jan 21, 2013 at 6:04 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
[...] WeakMap.prototype.clear questions the property that was true
before its adoption (you can only modify a weakmap entry if you
have
Le 21/01/2013 22:31, Tom Van Cutsem a écrit :
Let's talk through Allen and Brandon's suggestion of auto-unwrapping
private symbol access on proxies.
If a membrane can intercept all exchanged private symbols I think this
could be made to work.
Agreed. Unfortunately, I think the condition (If a
On Tue, Jan 22, 2013 at 5:56 AM, David Bruant bruan...@gmail.com wrote:
Le 22/01/2013 11:47, Jason Orendorff a écrit :
On Mon, Jan 21, 2013 at 6:04 AM, David Bruant bruan...@gmail.com wrote:
[...] WeakMap.prototype.clear questions the property that was true before
its adoption (you can
On Tue, Jan 22, 2013 at 5:56 AM, David Bruant bruan...@gmail.com wrote:
However, Mark showed an elegant way to implement .clear on top of
clear-less weakmaps and the class syntax [4][5] (reproducing here the final
version for clarity)
Sure—and roughly the same code can be used to *remove* an
Le 22/01/2013 15:19, Jason Orendorff a écrit :
On Tue, Jan 22, 2013 at 5:56 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 22/01/2013 11:47, Jason Orendorff a écrit :
On Mon, Jan 21, 2013 at 6:04 AM, David Bruant bruan...@gmail.com
2013/1/22 David Bruant bruan...@gmail.com
Le 21/01/2013 22:31, Tom Van Cutsem a écrit :
Let's talk through Allen and Brandon's suggestion of auto-unwrapping
private symbol access on proxies.
If a membrane can intercept all exchanged private symbols I think this
could be made to work.
Le 22/01/2013 16:02, Tom Van Cutsem a écrit :
2013/1/22 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
Le 21/01/2013 22:31, Tom Van Cutsem a écrit :
Let's talk through Allen and Brandon's suggestion of
auto-unwrapping private symbol access on proxies.
If
2013/1/22 Allen Wirfs-Brock al...@wirfs-brock.com
We can probably fix the built-ins with some ad hoc language about them
automatically resolving proxies to the target as the this value. Or perhaps
we could expand the internal MOP api to include a resolve proxy to target
operation.
Using
Kevin Smith wrote:
In ES5, there is no distinction between public and private data within
an object. If you want to create private data, you must do so using a
closure. All private data is therefore external to the object in
question. The data does not follow the object around. This is a
On Tue, Jan 22, 2013 at 2:47 AM, Jason Orendorff
jason.orendo...@gmail.com wrote:
On Mon, Jan 21, 2013 at 6:04 AM, David Bruant bruan...@gmail.com wrote:
[...] WeakMap.prototype.clear questions the property that was true before
its adoption (you can only modify a weakmap entry if you have the
The fact that ES built-ins' methods are defined on the prototype **and** have
access to private data seems to indicate that the ideal model would allow
both. WeakMaps do, to a degree, permit both, but it's just a hack. If it
wasn't, the ES spec itself would describe built-ins' private data
I also agree with everything that Nathan said.
To clarify, there's Symbols and then there's private Symbols. I don't think
anyone in TC39 is suggesting the removal of Symbols in general. Private
Symbols have a much more specific set of uses cases than do just Symbols in
general, and regular
On Tue, Jan 22, 2013 at 9:01 AM, David Bruant bruan...@gmail.com wrote:
class WeakMapWithoutClear {
Yep. Glad to see we are thinking along the same lines.
What this and my previous show is an semantics equivalence between
clearable and clear-less weakmaps. Which should be chosen as
On Jan 22, 2013, at 7:18 AM, Mark S. Miller wrote:
But WeakMaps were introduced specifically to support rights
amplification[1].
Perhaps, from your perspective, but not from mine. The above is certainly not
a phrase I would ever say, I'm not even sure of your exact technical definition
Kevin Smith pointed out something I hadn't though about before but is
obvious in retrospect. The hazard that proxies bring to the language in
general: proxies make it possible to break the target object by
inconsistently handling forwarding during the operation of methods.
class Counter {
On Tue, Jan 22, 2013 at 8:13 AM, Brandon Benvie
bran...@brandonbenvie.com wrote:
I also agree with everything that Nathan said.
To clarify, there's Symbols and then there's private Symbols. I don't think
anyone in TC39 is suggesting the removal of Symbols in general. Private
Symbols have a
On Jan 22, 2013, at 9:06 AM, Brandon Benvie wrote:
Kevin Smith pointed out something I hadn't though about before but is obvious
in retrospect. The hazard that proxies bring to the language in general:
proxies make it possible to break the target object by inconsistently
handling
On Tue, Jan 22, 2013 at 11:13 AM, Brandon Benvie
bran...@brandonbenvie.comwrote:
I also agree with everything that Nathan said.
To clarify, there's Symbols and then there's private Symbols. I don't
think anyone in TC39 is suggesting the removal of Symbols in general.
Private Symbols have a
Le 22/01/2013 16:13, Tom Van Cutsem a écrit :
2013/1/22 Allen Wirfs-Brock al...@wirfs-brock.com
mailto:al...@wirfs-brock.com
We can probably fix the built-ins with some ad hoc language about
them automatically resolving proxies to the target as the this
value. Or perhaps we could
Le 21/01/2013 22:42, Allen Wirfs-Brock a écrit :
On Jan 21, 2013, at 12:25 PM, David Bruant wrote:
Le 21/01/2013 20:52, Allen Wirfs-Brock a écrit :
On Jan 21, 2013, at 11:36 AM, Rick Waldron wrote:
This is the reality check I can get behind—I'm hard pressed to come up with a
use case that
2013/1/22 David Bruant bruan...@gmail.com
Just realizing now, but how does the membrane do the symbol unwrapping
if private symbols pierces it?
2 contexts A and B share a symbol, the symbol initially has to go through
a public channel (get trap with a string name for instance) and if A
It's my opinion that saying that closures should be used for an object
to hold onto private data, as you are advocating, is in conflict with ES's
prototypal model of inheritance. Methods cannot both (A) be on a
constructor's prototype and (B) live inside the scope used to house
private data.
[Merging a couple of relevant posts]
Le 22/01/2013 15:59, Jason Orendorff a écrit :
Now, the only thing that can differentiate both the native against
this version is performance I think. Allen seems to argue that a
native .clear would have better perf characteristics (related to
Le 22/01/2013 20:05, Tom Van Cutsem a écrit :
2013/1/22 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
Just realizing now, but how does the membrane do the symbol
unwrapping if private symbols pierces it?
2 contexts A and B share a symbol, the symbol initially has to go
This is very well said. But your assertion that the external model is
unnatural does not necessarily hold. Again, let's look at this private
syntax and expansion using WeakMaps:
https://gist.github.com/4561871
This syntax presents an external model of private data (and methods!).
Do you think
+1 to this and everything else Nathan has said. Watching all this intense
back and forth, there are a lot of good points, some of which almost
convince me that weak maps are sufficient and private symbols are
unnecessary. But when I step back for even a minute, as a developer private
symbols
Le 22/01/2013 15:59, Jason Orendorff a écrit :
A) Are there more WeakMap applications that will want .clear() or
applications that will want .clear() not to exist? Offhand I would bet
on the former, by a landslide, but if you think otherwise, or if
there's some other reason to privilege
On Tue, Jan 22, 2013 at 1:55 PM, David Bruant bruan...@gmail.com wrote:
For reference, quote from Allen:
generational collectors can have large latencies between the time the last
reference to an object is destroyed and the when the GC actually notices.
Many GC cycles may occur during that
On Tue, Jan 22, 2013 at 4:03 PM, Kevin Smith khs4...@gmail.com wrote:
+1 to this and everything else Nathan has said. Watching all this intense
back and forth, there are a lot of good points, some of which almost
convince me that weak maps are sufficient and private symbols are
unnecessary.
On Tue, Jan 22, 2013 at 1:46 PM, Jason Orendorff
jason.orendo...@gmail.com wrote:
On Tue, Jan 22, 2013 at 1:55 PM, David Bruant bruan...@gmail.com wrote:
For reference, quote from Allen:
generational collectors can have large latencies between the time the last
reference to an object is
Thanks a lot for these explanations! (Answer below)
Le 22/01/2013 22:46, Jason Orendorff a écrit :
Having said all that, I bet we could hack around the worst-case
GC performance. It'll be a pain, but GC is like that sometimes.
What you said above about the current GC setup that
On Jan 22, 2013, at 2:35 PM, David Bruant wrote:
So, to find out if a weakmap is dead, it has to come from another source than
the mark-and-sweep algorithm (since it losts its precision)...
Given the additional prohibitive cost weakmaps seem to have on the GC, maybe
things that would
Should Symbols (whether unique or private) also have a .clear method,
in order to delete all properties named by that symbol?
On Tue, Jan 22, 2013 at 3:36 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Jan 22, 2013, at 2:35 PM, David Bruant wrote:
So, to find out if a weakmap is dead,
On Jan 22, 2013, at 4:00 PM, Mark S. Miller wrote:
Should Symbols (whether unique or private) also have a .clear method,
in order to delete all properties named by that symbol?
Of course not. A Symbol is basically a simple immutable value disguised as an
object. The is no interesting
A Duck/Rabbit Proposal:
1) There is only one kind of Symbol
2) Private data can be accessed via Object.getPrivate and Object.setPrivate
The goal is to provide a base-level API from which higher-level
abstractions can be built.
// === Basic example ===
var symbol = new Symbol(), obj =
Brandon Benvie wrote:
It is my opinion that the primary use case for private symbols is for
properties that proxies expressly shouldn't be given a chance, in any
manner, to corrupt or modify. They are likely used for sensitive
internal state that will only be accessed by methods or friend
My initial reaction:
- Hosting getPrivate/setPrivate on Object seems quite strange to me.
- it seems unrealistic to me to ask developers to write so much code every time
they want to use their own private instance variable. The notion of Private
should be specified once for an instance
I would like to humbly say that if this `WeakMap#clear()` method is anyhow
slowing down or reminding the adoption of the WeakMap concept itself for
all browsers, just mark it TBD and go on with the rest: WeakMap is needed
and wanted since ever, `clear()` gotchas can be discussed for all the time
40 matches
Mail list logo
