Private getters and setters

[littledan]

Should we have these?

In particular, for a use case, some frameworks (cc @wycats @diervo) have mentioned a desire to have a way to observe changes in private fields. The full-on vision for this might be a decorator which transforms a private field declaration into a private getter/setter pair, with the underlying storage in a separate, generated private field.

[allenwb]

Currently, the object model defined by the private state proposal doesn't include the concept of private getters and setters, so a first step would be to extend that object model to include them.

But, I don't really think there would be very useful. Consider that private fields can only be referenced from within the lexical scope of the private field definition. I.e, from within the class body that defines the private field. This is different from object properties that that can be arbitrarily accessed by any code that has access to the object. While getters are useful to intermediate in such arbitrary property accesses, they seem unnecessary for private field all of whose accesses statically exist in the same source code class body as the definition of the field. Why is there a need to "observe" such accesses when the author of the code already had to write the code of the access. If the author wants some action to occur as a side-effect of the access all they need to do is to write the code such that they invoke the side-effect immediate after performing the access.

If such an access/side-effect occurs many places in a class body, then it might be useful to write a helper function that encapsulates both the access and the side-effect. Lexically scoped function definitions within a class body would be a nice way to support such helper that doesn't require extending the object model.

[diervo]

You articulated perfectly the key question:

Why is there a need to "observe" such accesses when the author of the code already had to write the code of the access.

The reason is fundamentally ergonomics: You don't want to create a helper method for side-effects in all your private access/sets, but rather abstract it via getter/setter, even better, defining the setter/getters outside the class (still within the same lexical scope).

This is specially useful for frameworks, for example to keep track when something is mutated within a class, to be able to efficiently decide what to do next based on those mutations. We want to abstract the side effects from user-land (the framework will provide the getters and setters), while keeping the private semantics. So no manually helpers are not a requirement.

That being said, in a email thread we agreed that we should keep the private fields implementation as is for now, and explore the side effects via decorators, so that will give us enough insights wether to pursue the getters/setters for private fields.

I have yet to merge my PR in Babylon to allow the private fields syntax, and also we need a new plugin with the latests decorator semantics.