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
