Kevin Smith wrote:
I think of this fact as rather supporting my view, because freezing is
no longer freezing the whole object, as before.
It's really none of your business when you try to freeze my object
whether any of
(a) pre-existing private-symbol-named properties remain writable;
(b)
Le 14/01/2013 19:21, Claus Reinke a écrit :
From the teachability perspective, I'm tired of explaining the
closure hack to explain private properties. Even to some who are
experienced webdevs, I have to explain that they can't access the
private property through this..
The language needs to
Le 15/01/2013 06:53, Dmitry Soshnikov a écrit :
On Jan 14, 2013, at 9:32 PM, Dmitry Soshnikov wrote:
Hello,
Don't know whether it was mentioned/asked before (sorry if so), but just a
note: probably it makes more sense making the target argument as optional and
the second one in the Proxy
It's really none of your business when you try to freeze my object
whether any of
(a) pre-existing private-symbol-named properties remain writable;
(b) weakmap-encoded private state remains writable;
(c) objects-as-closures environment variables remain writable.
Really. Not. Your (user).
Hi Mark,
I have a couple of comments:
* On the share-nothing model
This comment goes beyond the paper, but I think is relevant for future work.
Practice of the event loop model in JavaScript has proven that the
share-nothing model has limitations. In my opinion, one of the reasons
WebWorkers
I have suggested before that it would be good to put control
over object iteration into the hands of the object authors, by
enabling them to override the slot iteration method.
One would need to find a way of doing so without exposing private names,
but it should allow object authors to
It's really none of your business when you try to freeze my object whether
any of
(a) pre-existing private-symbol-named properties remain writable;
(b) weakmap-encoded private state remains writable;
(c) objects-as-closures environment variables remain writable.
Really. Not. Your.
The variable was called s standing for secret. The example I gave was
dummy, but examples in the wild are legion. Take your favorite node
library. Anytime it defines a _property, this is where there should be a
private name.
Again, that's arguable. Certainly it would be better expressed
Perhaps one useful aspect to add to this discussion is the distinction
between
* contracts as implemented as a DSL (as in Racket)
* contracts (aka attenuators/...) implemented as code
Both achieve the same functionality of constraining behavior.
Contracts-as-code may be more flexible but may
On Jan 15, 2013, at 12:54 AM, David Bruant wrote:
Le 15/01/2013 06:53, Dmitry Soshnikov a écrit :
On Jan 14, 2013, at 9:32 PM, Dmitry Soshnikov wrote:
Hello,
Don't know whether it was mentioned/asked before (sorry if so), but just a
note: probably it makes more sense making the target
Brendan Eich wrote:
Object.freeze deals in certain observables. It does not free
(freeze, of course.)
closure state, or weakmap-encoded state, or (per the ES6 proposal)
private-symbol-named property state where such properties already
exist. Those are not directly observable by the
Sure - and approaches like this (or simpler - people are clever!) can
be factored away into a neat library, without having to mess with the
underlying object model.
ES6 provides WeakMaps and Proxies. Why not see what people do with
those before introducing private slots?
Is it really
(b) is a change from ES5 but you don't object to weak maps -- why not?
WeakMaps provide a new feature without extending the object model. They
are external to objects, if you like.
(c) is not a change from JS's object model!
Sure - but I'm not objecting to closed-over state (in any
Kevin Smith wrote:
(b) is a change from ES5 but you don't object to weak maps -- why not?
WeakMaps provide a new feature without extending the object model.
They are external to objects, if you like.
They are a kind of object, on the contrary.
(c) is not a change from JS's
2013/1/10 Brendan Eich bren...@mozilla.com
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
2013/1/9 David Bruant bruan...@gmail.com
Le 09/01/2013 20:30, Allen Wirfs-Brock a écrit :
That still doesn't mean that such a spec. writer doesn't need to
understand the ES object invariants as they shouldn't be writing any
specification requirments that violates those invariants.
What I'm
Le 15/01/2013 17:16, Kevin Smith a écrit :
The variable was called s standing for secret. The example I
gave was dummy, but examples in the wild are legion. Take your
favorite node library. Anytime it defines a _property, this is
where there should be a private name.
Again,
Le 15/01/2013 20:32, Tom Van Cutsem a écrit :
2013/1/10 Brendan Eich bren...@mozilla.com mailto:bren...@mozilla.com
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
Le 15/01/2013 21:06, Herby Vojčík a écrit :
David Bruant wrote:
ES6 provides WeakMaps and Proxies. Why not see what people do with
those before introducing private slots?
I wouldn't be opposed to that, but that's just my opinion. Still,
private symbols allow property-like syntax. I haven't
2013/1/15 Dmitry Soshnikov dmitry.soshni...@gmail.com
Sure, and it (the target) still would be there, just created implicitly.
All the invariants are kept, the storage (the implicit target) is kept.
But, that's mentioned, if the target is implicit, then handler functions
look a bit weird
Le 15/01/2013 19:19, Kevin Reid a écrit :
On Tue, Jan 15, 2013 at 2:20 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Practice of the event loop model in JavaScript has proven that the
share-nothing model has limitations. In my opinion, one of the
reasons
2013/1/15 David Bruant bruan...@gmail.com
Le 15/01/2013 20:32, Tom Van Cutsem a écrit :
As far as I recall, the purpose of the trap was to allow a membrane or
revocable proxy to explicitly abort accesses involving such private
symbols. The point being that if a membrane can't abort such
Very fair response -- thanks. I want to add praise for Kevin, he asks
the right questions, especially the one to which I replied hold that
thought:
Maybe it's worth it, I don't know. That's the whole point: I don't
know. And when in doubt...
We certainly did leave out something in
On Tue, Jan 15, 2013 at 12:49 PM, David Bruant bruan...@gmail.com wrote:
Le 15/01/2013 19:19, Kevin Reid a écrit :
From a capability viewpoint, there are non-performance reasons to have
the same pattern, even within a given event loop, namely resources which
may be transferred with
Tom Van Cutsem wrote:
2013/1/15 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
Le 15/01/2013 20:32, Tom Van Cutsem a écrit :
As far as I recall, the purpose of the trap was to allow a
membrane or revocable proxy to explicitly abort accesses involving
such private
On Tue, Jan 15, 2013 at 12:10 PM, Tom Van Cutsem tomvc...@gmail.com wrote:
In defense of Kevin, I too would argue that private symbols add complexity
to the object model.
That doesn't mean I'm arguing in favor of removing private symbols, just
noting that we do pay a complexity price.
We
David Bruant wrote:
In theory, private symbols should have the same GC issues than
WeakMap. Consider:
var o = {}, o2 = {};
for(var i=0, i1000, i++){
let s = new Symbol(true /*private*/);
o[s] = o2[s] = i;
}
Here, private symbols are created, properties are added.
The GC cost is one problem, but the property access cost is another, and
the second allocation (wm for every obj) yet another. And as Dean just
reminded, prototypal inheritance favors symbols. It's not just one cost
that motivates symbols over weakmaps if the goal is OO privacy.
/be
On Tue, Jan 15, 2013 at 1:56 PM, Brendan Eich bren...@mozilla.com wrote:
David Bruant wrote:
In theory, private symbols should have the same GC issues than WeakMap.
Consider:
var o = {}, o2 = {};
for(var i=0, i1000, i++){
let s = new Symbol(true /*private*/);
o[s]
Mark S. Miller wrote:
On Tue, Jan 15, 2013 at 1:56 PM, Brendan Eichbren...@mozilla.com wrote:
David Bruant wrote:
In theory, private symbols should have the same GC issues than WeakMap.
Consider:
var o = {}, o2 = {};
for(var i=0, i1000, i++){
let s = new Symbol(true
On Tue, Jan 15, 2013 at 2:27 PM, Brendan Eich bren...@mozilla.com wrote:
Mark S. Miller wrote:
On Tue, Jan 15, 2013 at 1:56 PM, Brendan Eichbren...@mozilla.com wrote:
David Bruant wrote:
In theory, private symbols should have the same GC issues than WeakMap.
Consider:
var o = {},
On Jan 15, 2013, at 1:58 PM, Brendan Eich wrote:
The GC cost is one problem, but the property access cost is another, and the
second allocation (wm for every obj) yet another. And as Dean just reminded,
prototypal inheritance favors symbols. It's not just one cost that motivates
symbols
On Tue, Jan 15, 2013 at 3:03 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Jan 15, 2013, at 1:58 PM, Brendan Eich wrote:
The GC cost is one problem, but the property access cost is another, and the
second allocation (wm for every obj) yet another. And as Dean just reminded,
We've previously concluded that RegExp.prototype.compile is part of web reality
and should be included in the ES6 spec. Whether it is put in the main spec. or
in Annex B doesn't make a difference for the technical issue I'm about to
discuss.
Currently RegExp instances are specified to have
#3. If any ES5 or __lookupGetter__ code breaks, I'll be surprised, but
also willing to say too bad.
/be
Allen Wirfs-Brock wrote:
We've previously concluded that RegExp.prototype.compile is part of web reality
and should be included in the ES6 spec. Whether it is put in the main spec. or
in
My answer depends on a prior issue. Do we agree that in ES6,
RegExp.prototype is not itself a RegExp? Like the Date.prototype and
WeakMap.prototype we've already talked about, freezing it and
everything reachable from it must render it immutable, so that it
isn't a communications channel. SES
I think you now understand my proposal. By simple, I meant for
users, not implementors. I have no other disagreement with your
conclusion.
On Tue, Jan 15, 2013 at 5:00 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Jan 15, 2013, at 3:46 PM, Mark S. Miller wrote:
On Tue, Jan 15, 2013 at
Hi David, E uses a different trick. E objects that are marked as
transitively immutable and transitively identity-less can be safely
passed between vats in one address space by pointer sharing rather
than copying. For these objects, this optimization has no semantics.
JS has no identity-less
On Tue, Jan 15, 2013 at 6:21 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Jan 15, 2013, at 6:10 PM, Mark S. Miller wrote:
Thanks. That's what I thought, but wanted to be sure.
In that case, I have no objections to any of these proposals, but I prefer
#4.
I really think whenever
These use cases can be made dynamic be some kind of
Proxy.fromNowOnForwardUnknownPrivateSymbols(proxy, false);
API. This is not truly dynamic. I'd say no truly dynamic use cases
exist, where you must decide _at_the_exact_point_of_access_. IMO.
I would be ok with something more along the
set(key, value) {
let data = this[$data];
if (!data)
throw new TypeError('this object must be a StringMap');
if (!(key in data))
this[$size]++;
data[key] = value;
}
Doh! I wrote that in such a way that an inconsistency cannot be introduced,
since
41 matches
Mail list logo
