Re: Public/private namespaces in harmony classes proposal
Might it be reasonable to make private properties be regular properties on the object, with a new 'private' attribute, similar to the existing writable/configurable attributes? From the perspective of code outside of the associated class, an instance's private property would be non-readable, non-writable and non-configurable (likely also non-enumerable?), with any attempt to get, set, or delete the property failing in a similar manner to an existing writable/configurable attribute violation. It would be great to hear your thoughts on this. See above -- private means you can't probe, let alone collide, for the private name from outside of the abstraction. Private name objects prove much more than a single-bit 'private' attribute -- they allow private, protected, friend, shared-secret, and public-but-guarnateed-unique names. /be Got it, cheers gents. G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Public/private namespaces in harmony classes proposal
On Jul 7, 2011, at 9:49 PM, Mark S. Miller wrote: On Thu, Jul 7, 2011 at 9:41 PM, Gavin Barraclough barraclo...@apple.com wrote: Hi Mark, In the harmony classes proposal, http://wiki.ecmascript.org/doku.php?id=harmony:classes , I'm interested in understanding the following issue: One or two namespaces for public properties and private instance variables [RESOLVED two, Mark’s argument] Do you remember if this argument was made in email, and if so would anyone happen to know where to look to find this (I've tried a little googling to no avail!), I'd be interested in understanding the rationale behind this decision. I don't think it was made in before in email. Here goes: For non-const classes, their instances are extensible by default. Even if you disagree with this default, I think we generally agree that there should at least be an option to make extensible instances. Say public and private share one namespace. Say extensible instance X has private instance property 'foo'. Say a client of X tries to extend it with a public 'foo' property. What happens? Ah, I see. It's a fair point, but isn't this already a hazard that the language faces? Suppose I have two objects, extensible instance X with private instance property 'foo', and extensible object Y upon which I have defined a property 'foo' using Object.defineProperty, setting writable=false. If a client of Y tries to extend if with a public 'foo' property, then this would fail (throwing a TypeError in strict mode code). Would it not be acceptable for the attempted assignment to the private property of X to fail in a similar fashion? It seems that it is already the case that if a client wishes to associate data with a given object under any arbitrary name, then the only truly safe way to do so is through an external mapping such as a weak map / ephemeron table? Might it be reasonable to make private properties be regular properties on the object, with a new 'private' attribute, similar to the existing writable/configurable attributes? From the perspective of code outside of the associated class, an instance's private property would be non-readable, non-writable and non-configurable (likely also non-enumerable?), with any attempt to get, set, or delete the property failing in a similar manner to an existing writable/configurable attribute violation. It would be great to hear your thoughts on this. cheers, G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Public/private namespaces in harmony classes proposal
On Jul 7, 2011, at 11:07 PM, Gavin Barraclough wrote: Ah, I see. It's a fair point, but isn't this already a hazard that the language faces? Not with private names. Suppose I have two objects, extensible instance X with private instance property 'foo', and extensible object Y upon which I have defined a property 'foo' using Object.defineProperty, setting writable=false. If a client of Y tries to extend if with a public 'foo' property, then this would fail (throwing a TypeError in strict mode code). Would it not be acceptable for the attempted assignment to the private property of X to fail in a similar fashion? No, that leaks the fact that there's a private-named object (if you also enumerate public names and do not find such a name; or enumerate property descriptors, etc.). It seems that it is already the case that if a client wishes to associate data with a given object under any arbitrary name, then the only truly safe way to do so is through an external mapping such as a weak map / ephemeron table? No, private names are in ES.next: http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects Might it be reasonable to make private properties be regular properties on the object, with a new 'private' attribute, similar to the existing writable/configurable attributes? From the perspective of code outside of the associated class, an instance's private property would be non-readable, non-writable and non-configurable (likely also non-enumerable?), with any attempt to get, set, or delete the property failing in a similar manner to an existing writable/configurable attribute violation. It would be great to hear your thoughts on this. See above -- private means you can't probe, let alone collide, for the private name from outside of the abstraction. Private name objects prove much more than a single-bit 'private' attribute -- they allow private, protected, friend, shared-secret, and public-but-guarnateed-unique names. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Public/private namespaces in harmony classes proposal
On Jul 7, 2011, at 11:15 PM, Brendan Eich wrote: Suppose I have two objects, extensible instance X with private instance property 'foo', and extensible object Y upon which I have defined a property 'foo' using Object.defineProperty, setting writable=false. If a client of Y tries to extend if with a public 'foo' property, then this would fail (throwing a TypeError in strict mode code). Would it not be acceptable for the attempted assignment to the private property of X to fail in a similar fashion? No, that leaks the fact that there's a private-named object er, private property on the object. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Public/private namespaces in harmony classes proposal
On Fri, Jul 8, 2011 at 3:15 AM, Brendan Eich bren...@mozilla.com wrote: On Jul 7, 2011, at 11:07 PM, Gavin Barraclough wrote: Ah, I see. It's a fair point, but isn't this already a hazard that the language faces? Not with private names. There's also something that was probably discussed but never got to this list: Private instance properties were considered to be accessible by all instances of the class. That's a new concept in ES. Were there arguments for keeping instance private properties private to the instance? Juan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Public/private namespaces in harmony classes proposal
On Fri, Jul 8, 2011 at 6:36 AM, Juan Ignacio Dopazo
dopazo.j...@gmail.comwrote:
On Fri, Jul 8, 2011 at 3:15 AM, Brendan Eich bren...@mozilla.com wrote:
On Jul 7, 2011, at 11:07 PM, Gavin Barraclough wrote:
Ah, I see. It's a fair point, but isn't this already a hazard that the
language faces?
Not with private names.
There's also something that was probably discussed but never got to this
list:
Private instance properties were considered to be accessible by all
instances of the class. That's a new concept in ES. Were there arguments for
keeping instance private properties private to the instance?
Yes. That's done quite well by lexical capture of the constructor lexical
context by per-instance methods:
class Point {
constructor(x, y) {
public getX() { return x; }
...
}
}
which basically sugars the objects-as-closure pattern. If you don't mind the
allocation cost, this is superior in almost all ways to the conventional
prototype/this-based pattern.
private is needed when combining inherited methods with encapsulation.
Since inherited methods may apply to any instance of the class and are not
automagically bound to any one instance, their access to encapsulated state
cannot be any finer than per-class.
Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Public/private namespaces in harmony classes proposal
On Jul 8, 2011, at 6:36 AM, Juan Ignacio Dopazo wrote: On Fri, Jul 8, 2011 at 3:15 AM, Brendan Eich bren...@mozilla.com wrote: On Jul 7, 2011, at 11:07 PM, Gavin Barraclough wrote: Ah, I see. It's a fair point, but isn't this already a hazard that the language faces? Not with private names. There's also something that was probably discussed but never got to this list: Private instance properties were considered to be accessible by all instances of the class. That's a new concept in ES. Were there arguments for keeping instance private properties private to the instance? Yes, on this list, going back to the Harmony Oslo July 2008 meeting, with followup at the Kona Nov. 2008 meeting. Mark may have notes from the more recent sub-group of TC39ers who championed classes. My recollection is that we chose class-private for both usability and private-name equivalence, but we still have open issues on how one accesses private foo in both |this| and |other| for a dyadic operator method, e.g. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Public/private namespaces in harmony classes proposal
On Jul 8, 2011, at 7:43 AM, Juan Ignacio Dopazo wrote: My first thought was: why not just statically replace this.x, with private x, with this[xPrivateName] and forget about accessing private properties of other objects? That would still leave the problem of closures inside methods, though... If xPrivateName is a private name object, then there's no reason to forget about accessing private properties of other objects. Both this[xPrivateName] and other[xPrivateName] work as you would expect. /be___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Public/private namespaces in harmony classes proposal
On Fri, Jul 8, 2011 at 12:15 PM, Brendan Eich bren...@mozilla.com wrote: On Jul 8, 2011, at 7:43 AM, Juan Ignacio Dopazo wrote: My first thought was: why not just statically replace this.x, with private x, with this[xPrivateName] and forget about accessing private properties of other objects? That would still leave the problem of closures inside methods, though... If xPrivateName is a private name object, then there's no reason to forget about accessing private properties of other objects. Both this[xPrivateName] and other[xPrivateName] work as you would expect. /be You are very much right. What are the open issues with privates in classes then? Juan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Public/private namespaces in harmony classes proposal
On Fri, Jul 8, 2011 at 1:52 PM, Brendan Eich bren...@mozilla.com wrote:
On Jul 8, 2011, at 8:45 AM, Juan Ignacio Dopazo wrote:
You are very much right. What are the open issues with privates in classes
then?
The wiki lists some. Here are a few from memory:
* Syntax to use instead of private(this), private(other). The straw
private(foo) syntax is too verbose and it wrongly suggests that a private
data record is a distinct object. Are we ready to claim @ as prefix and
infix operator (with restriction against LineTerminator on its left)?
Why do privates need special syntax? Isn't the point to just use them with
this.privateWhatever?
* Private prototype methods and other properties may be useful, especially
methods. One can wrap a closure around the class and put private helpers
there, of course, but with private syntax in the proposal, why stop short?
+1!
If we do support private prototype properties, then what are the semantics?
Private name objects, as recently noted, have their .public counterparts
passed as name parameters to proxy traps, so something about private
prototype properties may be observable:
class Victim prototypes Proxy { private protoMethod() {
privat(super).protoMethod(); } }
Isn't that only an issue of protected vs private?
Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Public/private namespaces in harmony classes proposal
On Jul 8, 2011, at 10:20 AM, Juan Ignacio Dopazo wrote:
On Fri, Jul 8, 2011 at 1:52 PM, Brendan Eich bren...@mozilla.com wrote:
On Jul 8, 2011, at 8:45 AM, Juan Ignacio Dopazo wrote:
You are very much right. What are the open issues with privates in classes
then?
The wiki lists some. Here are a few from memory:
* Syntax to use instead of private(this), private(other). The straw
private(foo) syntax is too verbose and it wrongly suggests that a private
data record is a distinct object. Are we ready to claim @ as prefix and infix
operator (with restriction against LineTerminator on its left)?
Why do privates need special syntax? Isn't the point to just use them with
this.privateWhatever?
No, because of the other.x problem:
class Point {
constructor(x, y) {...}
equals(other) { return this.x is other.x this.y is other.y; }
...
}
We cannot know how to ask for private-x from other without special syntax of
some kind, either at the access point or as a binding declaration affecting all
.x (and x: in object literals).
If we do support private prototype properties, then what are the semantics?
Private name objects, as recently noted, have their .public counterparts
passed as name parameters to proxy traps, so something about private
prototype properties may be observable:
class Victim prototypes Proxy { private protoMethod() {
privat(super).protoMethod(); } }
Isn't that only an issue of protected vs private?
Sorry, that may be a bad example. Consider the Point example above, where other
is a proxy and we use @ for private access:
class Point {
constructor(x, y) {...}
equals(other) { return @x is other@x @y is other@y; }
...
}
(The unary prefix form @foo is short for binary this@foo.)
The spec has to say what the proxy denoted by other sees as the name
parameter when its handler's relevant trap is called.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Public/private namespaces in harmony classes proposal
Hi Mark, In the harmony classes proposal, http://wiki.ecmascript.org/doku.php?id=harmony:classes , I'm interested in understanding the following issue: One or two namespaces for public properties and private instance variables [RESOLVED two, Mark’s argument] Do you remember if this argument was made in email, and if so would anyone happen to know where to look to find this (I've tried a little googling to no avail!), I'd be interested in understanding the rationale behind this decision. cheers, G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
