shortcut for private(this)
Let's not bikeshed class private syntax just yet. I mean, we could (es-discuss, right?) but I don't think it is productive.
And again, we do not want a reified "private state object", so private could not be a free expression. This also hurts private(other).weight
Brendan Eich wrote:
And again, we do not want a reified "private state object", so private could not be a free expression. This also hurts private(other).weight -- 'weight' is not an identifier in a "private state object", it has to be a private name object binding. Therefore we should avoid any syntax suggesting a first-class reflection of a private state object.
How do I do private(foo)[expression]? Or I don't (yes, it can be worked around by foo. at store[expression], but)?
This is why @foo for private name object bound to lexical identifier foo has been proposed. It also has the benefits of being shorter and matching some other languages near to JS.
I did not know. I have read the class proposal (I need to rework Empowered Data not to use @). I am all for @bar (or something), I like the concise syntax for "private property name" concept. In fact I wanted it, and wanted to propose something lot crazier (private keyword itself being modifier of the property name, so foo.private bar, foo[private expr]; but @ is better (except I don't know if it is []-friendly).
Herby Vojčík <mailto:herby at mailbox.sk> January 20, 2012 10:39 AM Brendan Eich wrote:
And again, we do not want a reified "private state object", so private could not be a free expression. This also hurts private(other).weight -- 'weight' is not an identifier in a "private state object", it has to be a private name object binding. Therefore we should avoid any syntax suggesting a first-class reflection of a private state object.
How do I do private(foo)[expression]? Or I don't (yes, it can be worked around by foo. at store[expression], but)?
No problem -- @foo[bar] is the same in abstract syntax as (@foo)[bar].
Brendan Eich wrote:
Herby Vojčík <mailto:herby at mailbox.sk> January 20, 2012 10:39 AM Brendan Eich wrote:
And again, we do not want a reified "private state object", so private could not be a free expression. This also hurts private(other).weight -- 'weight' is not an identifier in a "private state object", it has to be a private name object binding. Therefore we should avoid any syntax suggesting a first-class reflection of a private state object.
How do I do private(foo)[expression]? Or I don't (yes, it can be worked around by foo. at store[expression], but)?
No problem -- @foo[bar] is the same in abstract syntax as (@foo)[bar].
No, I asked for something else. How do it do: "get a private property of <<foo>> whose name is computed by <<expression>>"? Something like
foo.@[expr]? Or is there no way to do it? In other words, what is [] syntax for foo. at bar? foo.@["bar"]? foo["@bar"]?
On Fri, Jan 20, 2012 at 10:46, Herby Vojčík <herby at mailbox.sk> wrote:
No, I asked for something else. How do it do: "get a private property of <<foo>> whose name is computed by <<expression>>"? Something like foo.@[expr]? Or is there no way to do it? In other words, what is [] syntax for foo. at bar? foo.@["bar"]? foo["@bar"]?
@bar is a shorthand[] for this[bar] object. at bar is a shorthand[] for object[bar]
There is no way to compute a string "bar" to do the lookup since that would break private name encapsulation:
let object = ... { let key = Name.create() let secret = {} object. at key = secret }
There must be no way to get access to secret here.
[*] Using @ does not really invoke []. That is important if private names are going to work with the extended collection proposals Allen proposed. strawman:object_model_reformation
On Fri, Jan 20, 2012 at 10:59 AM, Erik Arvidsson <erik.arvidsson at gmail.com> wrote:
On Fri, Jan 20, 2012 at 10:46, Herby Vojčík <herby at mailbox.sk> wrote:
No, I asked for something else. How do it do: "get a private property of <<foo>> whose name is computed by <<expression>>"? Something like foo.@[expr]? Or is there no way to do it? In other words, what is [] syntax for foo. at bar? foo.@["bar"]? foo["@bar"]?
@bar is a shorthand[] for this[bar] object. at bar is a shorthand[] for object[bar]
There is no way to compute a string "bar" to do the lookup since that would break private name encapsulation:
let object = ... { let key = Name.create() let secret = {} object. at key = secret }
There must be no way to get access to secret here.
[*] Using @ does not really invoke []. That is important if private names are going to work with the extended collection proposals Allen proposed. strawman:object_model_reformation
Shorter Arv: Private Names are not strings, they're unforgeable objects. Thus, it's impossible by design to have an analog of foo["bar"+baz] for Private Names. I wrote a blog post about the subject: www.xanthir.com/blog/b4FJ0
Erik Arvidsson wrote:
let object = ... { let key = Name.create() let secret = {} object. at key = secret }
Oh, so all that foo. at bar does is to have different syntax for foo[bar], bar being private name? Than it's not as cool as I thought at all.
private keyword in class proposal did something a lot more convenient. It created private name behind the scenes and let people to use "private" properties with doing prvKeyA = Name.create(); prvKeyB = Name.create(); ... for all private keys they wanted to use. This was the purpose of private keyword.
It seems I was overjoyed prematurely... :-/
Herby
P.S.: Why not to let obj[privateName]? It is fine.
Hello,
I think private itself could be used as a shortcut to private(this). It may look for example like this:
class Foo { ... leq(other) { return private.weight <= private(other).weight; } ... }
It is not unprecedented, there already is a keyword that represents this as well as other object in a strange manner (super). So private can also be such a word.
I don't see any grammatical/parsing/syntanctic problems with this for the moment. Maybe you find one.
Herby
P.S.: Since it is very similar (and private.foo works everywhere, not only in constructor), it may be though of to remove 'private foo = bar;' in constructor in favour of 'private.foo = bar;'. But it is only sort of afterthought. Also, 'public baz = moo;' could then be changed by simple 'this.baz = moo;' to make code in constructor more akin to code used everywhere else.
Hello, I think private itself could be used as a shortcut to private(this). It may look for example like this: class Foo { ... leq(other) { return private.weight <= private(other).weight; } ... } It is not unprecedented, there already is a keyword that represents this as well as other object in a strange manner (super). So private can also be such a word. I don't see any grammatical/parsing/syntanctic problems with this for the moment. Maybe you find one. Herby P.S.: Since it is very similar (and private.foo works everywhere, not only in constructor), it may be though of to remove 'private foo = bar;' in constructor in favour of 'private.foo = bar;'. But it is only sort of afterthought. Also, 'public baz = moo;' could then be changed by simple 'this.baz = moo;' to make code in constructor more akin to code used everywhere else.