Hello,
well, (const-classes aside) I am looking at private store as an automatic
hidden private name indexed block (too implementation-like look, probably,
but helps to grasp the content). This code (horror from the design point,
managers don't do real work, but I can not come up with better use case)
shows some more aspects of this (as was told, private names should help
conflict-less monkey-patching)
class CounterManager {
incrementFor (client) {
private(client).c++;
}
startManage (client) {
private(client).c = 0;
}
countOf (client) {
return private(ciient).c;
}
}
Yes, I could use private name directly, but this grasps the idea from
another point of view.
And there may be use cases where instances of a classes want to access
private part of another instance of the same class (to do comparision, for
example, which is read-only, but maybe there are modifying use cases, too).
So I would propose that:
- if private(foo) is used to read a property value, it should silently
return undefined is there is no private block (with private name of the
actual scope) in foo
- if private(foo) is used to write a value into a property, it should try to
create private block (with name for the actual scope) if it does not exist
and then write to it
The latter also solves the const-class instances simply - it is not possible
to create such block for them, so it fails the same as any other attempt to
add propoerty to a frozen object.
But it is matter of point of view, mainly, what is private about? I like
broader views, if possible, so I see private as "privately scoped naming for
the use of class methods (as they see fit)" than "a way to make field in
instance only visible to method of a class" (which is, by the nature of its
formulation, imho much harder to implement because of all the constraints it
puts on it; general is often better).
Herby
-----Pôvodná správa-----
From: Mark S. Miller
Sent: Monday, January 09, 2012 5:52 PM
To: Herby Vojčík
Cc: [email protected]
Subject: Re: Does private(expr) create a private storage block?
Hi Herby, I looked back over the class proposal and found that it indeed
leaves this case ambiguous, as you point out. We have also not discussed it
in committee or even in separate side discussions in which I participated. I
don't have strong feelings about this for non-const classes. For const
classes, I think privates should always be declared in the constructor. I
would like to be able to always allocate instances of const classes of fixed
"shape", i.e., non-configurable / non-extensible, so that users don't have
to worry about whether they've enabled the resulting optimizations or
whether they have uncaught spelling errors.
For consistency, perhaps we should make similar requirements for privates of
non-const classes, but this isn't clear. If you have some arguments one way
or another, please post. Thanks.
On Mon, Jan 9, 2012 at 8:33 AM, Herby Vojčík <[email protected]> wrote:
Hello,
the current class proposal (as I read it) specifies that the private block
is created by first 'private foo[ = "bar"];' in the constructor. The
question is, what is constructor does not contain any private declarations,
but uses private, like this:
...
The question is: does private(this) create the private storage block in this
case?
Herby
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
