Re: Does private(expr) create a private storage block?
Sorry, misunderstood the question.
Andrea Giammarchi wrote:
On Fri, Jan 20, 2012 at 2:24 AM, Herby Vojčík he...@mailbox.sk
mailto:he...@mailbox.sk wrote:
Let the object created is foo. When calling foo.method(), it is
accessing private(foo), not private(objectWithPrivates), since this
is foo. If yes does not happen. Errors may happen since foo
probably does not have private space (my proposal in this thread is
touching this issue).
2. what if Object.create(objectWithPrivates, descriptor) ? would
descriptor methods be able to invoke objectWithPrivates.method()
with private(this) access in the function body? If yes, would that
private(this) refer to the objectWithPrivates? This would violate
the objectWithPrivates private concept, isn't it?
Object.create accept the __proto__ and a descriptor, I am not sure a
descriptor will/should ever have a private(this) configured unless
there is not a class for the descriptor but the list of
configurations won't make much sense, i.e.
{value: function () { this instanceof OuterClass /* not possible, it's
just an object */ }}
It is an error to use private keyword outside the class block. So, no
extension with private(this) using methods at all outside it.
If aforementioned Object.create would appear inside class block, then
according to actual state of the proposal, as I understand it, it is an
error to use private keyword, too. It can only be used in methods (and
constructor). But with I am less sure.
My proposal is to make use of private keyword much more liberated, in
that case if your Object.create would appear inside (any) class block,
it would work and added (that class's whose the class block is) private
access, outside class block it would not.
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Does private(expr) create a private storage block?
Hello,
Mark S. Miller wrote:
... 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.
It is written in class proposal:
- An efficient implementation. The private state should be allocated
with the instance as part of a single allocation, and with no undue
burden on the garbage collector.
- The ability to have private mutable state on publicly frozen objects.
Now it is the question, what does it say about fixed shape. Does
fixed shape mean no private can be added / deleted, but private
properties themselves can be mutated? Or is it the weaker the private
space must be created and is not removable (in frozen object), but it is
itself extensible and private properties are configurable and writable?
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.
I have more thoughts on this, even the proposal how to make it work
dynamically for non-const classes and fixed in const classes, but the
answer to previous question seems important.
I presume the answer is the latter, since with no undue burden on the
garbage collector could be read as if possible, blended in single
object. But I would like to hear from you.
On Mon, Jan 9, 2012 at 8:33 AM, Herby Vojčík he...@mailbox.sk
mailto:he...@mailbox.sk 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:
class Coutner {
constructor () {
this.reset();
}
increment () {
private(this).c++;
}
reset () {
private(this).c = 0;
}
get count () {
return private(this).c;
}
}
The reset method is part of the API. Conveniently, it resets the
state of the object to the initial state, so constructor is calling it.
The question is: does private(this) create the private storage block
in this case?
Herby
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Does private(expr) create a private storage block?
On Thu, Jan 19, 2012 at 1:00 PM, Herby Vojčík he...@mailbox.sk wrote: Hello, Mark S. Miller wrote: ... 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. It is written in class proposal: - An efficient implementation. The private state should be allocated with the instance as part of a single allocation, and with no undue burden on the garbage collector. - The ability to have private mutable state on publicly frozen objects. Now it is the question, what does it say about fixed shape. Does fixed shape mean no private can be added / deleted, but private properties themselves can be mutated? Or is it the weaker the private space must be created and is not removable (in frozen object), but it is itself extensible and private properties are configurable and writable? 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. I have more thoughts on this, even the proposal how to make it work dynamically for non-const classes and fixed in const classes, but the answer to previous question seems important. I presume the answer is the latter, since with no undue burden on the garbage collector could be read as if possible, blended in single object. But I would like to hear from you. For const classes specifically, my intention is that the private state object is sealed, i.e., it is non-extensible and all its properties are non-configurable, but generally writable unless declared otherwise. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Does private(expr) create a private storage block?
Mark S. Miller mailto:erig...@google.com January 19, 2012 2:38 PM For const classes specifically, my intention is that the private state object is sealed, i.e., it is non-extensible and all its properties are non-configurable, but generally writable unless declared otherwise. Hi Mark, just to clarify: we don't want any observable private state object in any revised classes proposal. It may be that the current proposal is a bit out of date on this, just in terms of terminology and its possible misinterpretation. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Does private(expr) create a private storage block?
Please read the disclaimers: the private(this) syntax is not going to be adopted, ever; private name objects and freeze details have been worked out separately; the classes proposal is out of date. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Does private(expr) create a private storage block?
Mark S. Miller wrote:
For const classes specifically, my intention is that the private state
object is sealed, i.e., it is non-extensible and all its properties
are non-configurable, but generally writable unless declared otherwise.
Ok, so I present the concerns and then the proposed solutions.
Concern I. An efficient implementation. The private state should be
allocated with the instance as part of a single allocation, and with no
undue burden on the garbage collector. (from the class proposal)
(the quote above is also part of this concern)
Concern II. The ability to have private mutable state on publicly frozen
objects. (from the class proposal)
I went as far as thinking of blending private state with the object
itself when possible (instances of const classes seemed to be such), but
this invalidates such optimization (unless freeze would magically left
private state writable).
Concern III. The ability to use private(foo) on any object and defining
private stqte lazily, if not present. (me)
Concern IV. No need for 'private foo [= bar];' construct, ability to use
'private(this).foo = bar | null;' instead having same outcome. (me)
Concern V. We don't want any observable private state object in any
revised classes proposal. It may be that the current proposal is a bit
out of date on this, just in terms of terminology and its possible
misinterpretation (Brendan Eich's reply to this thread)
Solution.
0. Define prvName as Name.create() for internal use of the private
keyword inside the class code.
1. Let 'private foo;' in construct be sugar for 'private(this).foo =
void 0;'.
2. Let 'private foo = bar;' in construct be sugar for
'private(this).foo = bar;'.
3. Read access to private(foo).bar should
- check if foo[prvName] exists
- if not, return undefined
- if yes, return foo[prvName].bar
4. Write access to private(foo).bar should
- check if foo[prvName] exists
- if not, try to foo[prvName] = null | {} (may raise errors)
- do foo[prvName].bar = valueToBeWritten (may raise errors)
The errors in 4. are fine - the former means the object is not
extensible, so lazy private state cannot be created, but it is
semantically ok; the latter means the private state itself is not
extensible or the property itself is read-only.
Why it works for const classes: It creates those properties in private
state, which are written (declaration is desugared to write) in
constructor. Then, the instance is frozen/sealed and the private state
is sealed.
Concern I: OK. Maybe smart compiler can do static analysis of the
constructor code and create the object prefilled. But I think developer
can do this as well, hinting nicely to the compiler by code like:
class Foo {
constructor () {
...
private(this).{
// all or majority of the private data
}
...
}
...
}
Concern II: Freezing object does not make private state itself frozen. OK.
Concern III: Solved by lazy creation of private state.
Concern IV: Solved by desugaring, making the cases identical, enabled by
lazy creation.
Concern V: prvName is not visible, private names are not in key list.
--
Cheers,
--MarkM
Herby
P.S.: I posted another thread with proposal for shortcut for
private(this), but it still did not reach the list (I see private(this)
as non-elegant, too).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Does private(expr) create a private storage block?
On Fri, Jan 20, 2012 at 2:24 AM, Herby Vojčík he...@mailbox.sk wrote:
Let the object created is foo. When calling foo.method(), it is accessing
private(foo), not private(objectWithPrivates), since this is foo. If yes
does not happen. Errors may happen since foo probably does not have private
space (my proposal in this thread is touching this issue).
Object.create accept the __proto__ and a descriptor, I am not sure a
descriptor will/should ever have a private(this) configured unless there is
not a class for the descriptor but the list of configurations won't make
much sense, i.e.
{value: function () { this instanceof OuterClass /* not possible, it's just
an object */ }}
I did not understand this question.
similar to what you are thinking about private.{prop} ... you answered
already
thanks and br
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
