On Wed, Jan 16, 2013 at 3:53 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Jan 16, 2013, at 3:20 PM, Brandon Benvie wrote:
It's worth noting that private Symbols *are* used by the ES6 spec to
solve a number of other problems currently. They are used to provide easy
to use hooks for
On 15 January 2013 17:16, Kevin Smith khs4...@gmail.com wrote:
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
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.
I might be missing something, but isn't this basically covered
with the enumerable flag?
There are several object
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).
Well stated, respect.
I think you are underweighting the utility of private symbols. The
counter-argument I want to make is: what if high-integrity privacy (via
weakmaps as you propose) as a popular practice would take off, but with
weakmaps there's no optimization (PICs, TI) as there is for
To compare the various scenarios, this is what (I believe) it looks like
for SES. In ES5, SES currently censors gOPN I believe, in order to
implement the equivalent of private keys and/or WeakMap. Given an ES6
runtime environment that only supported unique symbols, it would have to
censor
Below is a slight variation of the closure hack that allows using
private properties through this. The idea is to use the public 'this'
as prototype for the private 'this', using 'bind' to give instance
methods access to the private 'this'
Bound methods. Smart!
I come to wonder why you even need
On Wed, Jan 16, 2013 at 11:47 AM, Brandon Benvie
bran...@brandonbenvie.com wrote:
To compare the various scenarios, this is what (I believe) it looks like for
SES. In ES5, SES currently censors gOPN I believe, in order to implement the
equivalent of private keys and/or WeakMap.
SES includes
Indeed, I used SES as a kind of template for this theoretical future
framework faced with the wcenarios. It was a response to the idea that
private symbols are primarily valuable for a SES type use case where
security is paramount, versus regular encapsulation which is handled
adequately by unique
My position on private symbols.
My position on classes is and has always been that classes are worth
introducing into the language *only* if they give us, or can be used
with, an affordable means for true object encapsulation. Assuming
Allen is right about what actual implementors will do (which
Mark S. Miller wrote:
My position on private symbols.
My position on classes is and has always been that classes are worth
introducing into the language*only* if they give us, or can be used
with, an affordable means for true object encapsulation. Assuming
Allen is right about what actual
On Wed, Jan 16, 2013 at 3:48 PM, Brendan Eich bren...@mozilla.com wrote:
Mark S. Miller wrote:
My position on private symbols.
My position on classes is and has always been that classes are worth
introducing into the language*only* if they give us, or can be used
with, an affordable
On Jan 16, 2013, at 12:57 PM, Russell Leggett wrote:
On Wed, Jan 16, 2013 at 3:48 PM, Brendan Eich bren...@mozilla.com wrote:
Mark S. Miller wrote:
My position on private symbols.
My position on classes is and has always been that classes are worth
introducing into the language*only* if
Le 16/01/2013 21:48, Brendan Eich a écrit :
Mark S. Miller wrote:
My position on private symbols.
My position on classes is and has always been that classes are worth
introducing into the language*only* if they give us, or can be used
with, an affordable means for true object encapsulation.
It's worth noting that private Symbols *are* used by the ES6 spec to solve
a number of other problems currently. They are used to provide easy to use
hooks for overriding builtin functionality: @@hasInstance, @@create,
@@toStringTag, @@iterator, and @@ToPrimitive. Some of these (@@toStringTag,
On Jan 16, 2013, at 3:20 PM, Brandon Benvie wrote:
It's worth noting that private Symbols *are* used by the ES6 spec to solve a
number of other problems currently. They are used to provide easy to use
hooks for overriding builtin functionality: @@hasInstance, @@create,
@@toStringTag,
That's exactly how I was thinking of it. @@hasInstance and @@create live on
Function.prototype so the only protection a sandbox has from letting any
and all comers muck with them is in them not being reflected.
Overriding Function.prototype.@@create (and the custom ones e.g.
Boolean.@@create)
On Jan 16, 2013, at 4:03 PM, Brandon Benvie wrote:
That's exactly how I was thinking of it. @@hasInstance and @@create live on
Function.prototype so the only protection a sandbox has from letting any and
all comers muck with them is in them not being reflected.
Overriding
In this light, it may also make sense to make Function.prototype.@@create and
Function.prototype.@@hasInstance non-writable, non-configurable.
Regardless of the defaults, SES could presumably defend itself in the
same same way.
If you make Function.prototype.@@create non-writable,
That's true, restricting their ability to be modified quells that concern.
The only other concern would be to make sure there isn't any extension
points left open in the default builtins. For example, if Object.@@create
wasn't specified by default (and the algorithm still ended up deferring to
it,
It is difficult to use by its nature, it's the kind of thing that
implementors or maybe library authors would make use of. It exposes a hook
for what previously was a low level spec operation (the object allocation
part of construction).
On Wed, Jan 16, 2013 at 7:34 PM, Nathan Wall
On Jan 16, 2013, at 4:34 PM, Nathan Wall wrote:
In this light, it may also make sense to make Function.prototype.@@create
and
Function.prototype.@@hasInstance non-writable, non-configurable.
Regardless of the defaults, SES could presumably defend itself in the
same same way.
If you
On Jan 16, 2013, at 4:34 PM, Brandon Benvie wrote:
That's true, restricting their ability to be modified quells that concern.
The only other concern would be to make sure there isn't any extension points
left open in the default builtins. For example, if Object.@@create wasn't
specified
My position on private symbols.
My position on classes is and has always been that classes are worth
introducing into the language *only* if they give us, or can be used
with, an affordable means for true object encapsulation.
Classes want encapsulation, yes. But do they want
That's what happens with private in Java (I don't think most Java devs
think that the Reflect API makes their private attributes actually not
private). Java devs could make everything public, they choose not to
because the cost of putting public is the same as the cost of putting
private and
An explicit goal of ES6 is to support self hosting of important native
libraries including the DOM. Self hosting libraries will be practical only
if the self hosted implementation can approach native performance and that
includes any overhead for branding, where it is required. In my
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
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).
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
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
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 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
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: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,
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
On Mon, Jan 14, 2013 at 10:57 AM, Kevin Smith khs4...@gmail.com wrote:
When a property is added to an object using a private symbol, it creates a
new kind of slot: a private slot. It is clear from the design of the Proxy
API that this represents a fundamentally new extension to the ES object
On Jan 14, 2013, at 8:04 AM, Sam Tobin-Hochstadt wrote:
On Mon, Jan 14, 2013 at 10:57 AM, Kevin Smith khs4...@gmail.com wrote:
When a property is added to an object using a private symbol, it creates a
new kind of slot: a private slot. It is clear from the design of the Proxy
API that this
I (as one of the people who has advocated for symbols) disagree
entirely. The JS object model extension required for symbols is small
-- JS objects now map from either strings or symbols to values (plus
prototype inheritance, getters, setters, configurability,
writeability, and the other
On Mon, Jan 14, 2013 at 11:28 AM, Kevin Smith khs4...@gmail.com wrote:
I (as one of the people who has advocated for symbols) disagree
entirely. The JS object model extension required for symbols is small
-- JS objects now map from either strings or symbols to values (plus
prototype
As further evidence, the word private does not even occur in sections
8.1.6 and 8.1.6.1 of the current ES6 draft. These are the sections that
define the ES6 object model. Small changes and additions had to be made
to allow for property keys to be either strings or symbols but those
changes
Le 14/01/2013 16:57, Kevin Smith a écrit :
When a property is added to an object using a private symbol, it
creates a new kind of slot: a private slot. It is clear from the
design of the Proxy API that this represents a fundamentally new
extension to the ES object model.
On the very first
There is no new kind of slot. Symbols, private and otherwise, go in
exactly the same kind of slot as any other object property.
Slots keyed with private symbols have different, novel behavior. Behavior
that did not exist before. At the very least, these slots are:
1) Strongly
Unless I missed a beat, they are not unfreezable. They are exactly like
normal properties except they are not enumerated by any existing
method including gOPN.
On Monday, January 14, 2013, Kevin Smith wrote:
There is no new kind of slot. Symbols, private and otherwise, go in
exactly the same
No boilerplate, no additional runtime costs than what's necessary.
Arguably, all of those examples could be addressed by unique symbols.
Where is the need for strong runtime enforcement of encapsulation?
I would personally like to see answers to the following questions:
- Do private
On Jan 14, 2013, at 8:38 AM, Kevin Smith wrote:
There is no new kind of slot. Symbols, private and otherwise, go in
exactly the same kind of slot as any other object property.
Slots keyed with private symbols have different, novel behavior. Behavior
that did not exist before. At the
On Mon, Jan 14, 2013 at 11:50 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Jan 14, 2013, at 8:38 AM, Kevin Smith wrote:
There is no new kind of slot. Symbols, private and otherwise, go in
exactly the same kind of slot as any other object property.
Slots keyed with private
And again, `Object.freeze` can be thought of as simply enumerating the
accessible properties and freezes them, which works unchanged with
private symbols, since they are not reflectively accessible via
getOwnPropertyNames.
I think of this fact as rather supporting my view, because freezing
On Mon, Jan 14, 2013 at 12:47 PM, Kevin Smith khs4...@gmail.com wrote:
And again, `Object.freeze` can be thought of as simply enumerating the
accessible properties and freezes them, which works unchanged with
private symbols, since they are not reflectively accessible via
getOwnPropertyNames.
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 evolve to the point where people can write
The concept of freezing the whole object is the problem. If you
call `freeze` on a DOM object, does the page stop changing? Of course
not -- objects can have hidden state that you, the client of that
object, have no access to and thus no way to freeze. This isn't
something new being added
Le 14 janv. 2013 à 19:29, Kevin Smith khs4...@gmail.com a écrit :
The concept of freezing the whole object is the problem. If you
call `freeze` on a DOM object, does the page stop changing? Of course
not -- objects can have hidden state that you, the client of that
object, have no
—Claude
Le 14 janv. 2013 à 20:46, Claude Pache claude.pa...@gmail.com a écrit :
Le 14 janv. 2013 à 19:29, Kevin Smith khs4...@gmail.com a écrit :
The concept of freezing the whole object is the problem. If you
call `freeze` on a DOM object, does the page stop changing? Of course
Consider again the mixin scenario. A user wants to create a class with
private methods:
let privateMethod = new Symbol(true);
class C {
constructor() {}
[privateMethod]() { }
publicMethod() { this[privateMethod](); }
}
And then use that class as a mixin:
class D {
This is one thing that came to my mind a couple months ago, but there are a
number of ways to resolve this problem, such as:
function mixin(a, b) {
for (let name of Object.getOwnPropertyNames(b)) {
let desc = Object.getOwnPropertyDescriptor(b, name);
if
In order to satisfy security guarantees, properties which are keys on
private symbols are not returned by getOwnPropertyNames.
That's why the methods are bound to the original object.
I realize, however, that non-method properties don't work correctly this way
(so I probably just should
In order to satisfy security guarantees, properties which are keys on
private symbols are not returned by getOwnPropertyNames.
That's why the methods are bound to the original object.
Regardless of the this binding, the privately keyed method will not be
copied over from the source object
Regardless of the this binding, the privately keyed method will not
be copied over from the source object and hence will be undefined when
called.
I think you're not understanding. Here's a simpler example that runs in modern
ES engines:
var A = {
foo: function() {
70 matches
Mail list logo
