On Nov 2, 2011, at 11:29 AM, Brendan Eich <[email protected]> wrote:
> On Nov 2, 2011, at 11:17 AM, David Bruant wrote:
>
>>> See my reply to Kam. We're not sugaring instance-private ivars. I am
>>> proposing something we agreed to in Nov. 2008: sugaring class-private ivars.
>> Ok, that's what I was missing. What were the rationale? use cases?
>
Doesn't the latest harmony class proposal define private within the
constructor? I assume this proposal would supersede the Nov 2008 meeting
Grammar pasted below:
CallExpression : ... private ( AssignmentExpression ) ConstructorElement : ...
PrivateVariableDefinition PrivateVariableDefinition : private
ExportableDefinition
> The rationale is that most mainstream OO languages with the most users
> support class-private not instance-private ivars. Sorry, Smalltalkers!
>
In java one cannot access a private declaration in this way without defining a
protected getter/setter for example.
> Use cases are all around us in JS today, using public properties. Refactoring
> to private should not require rewriting to add getter/setter method, etc.
But if you are locking down a private var, isn't refactoring implied by your
statement 'avoid ... hostile attacks, on private data'.
Private instance vars would, for example, prevent the following:
class Account {
private balance = 0;
constructor(balance) {
@balance = balance;
}
compare(otheraccount) {
if(otheraccount@balance > 1000000) {
@balance += --otheraccount@balance;
}
if(@balance > otheraccount@balance) {
return 1;
} else if(@balance < otheraccount@balance) {
return -1;
}
return 0;
}
}
>
>
>>> You can make instance-private ivars yourself in the constructor using
>>> Name.create, and go to town. Knock yourself out! (I mean that in a good
>>> way, at least from where I sit :-P).
>> Hmm... Are you sure you can implement instance-private variables with no
>> leak?
>
> You'd need to use the closure pattern:
>
> class BnD {
> constructor(x) {
> const my_x = Name.create('x');
> this[my_x] = x;
> this.method1 = function (...) {...};
> ...
> this.methodN = function (...) {...};
> }
> }
>
> The method1..N functions can use my_x, no one else can.
In Crockford terminology, method1..N are 'privileged' functions, but come at
the cost of memory allocation per object.
Does class-private ivars enable the private names proposal? Eg, is there an
implicit dependency?
>
> /be
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
