On Friday, 18 May 2018 at 12:32:30 UTC, Mike Parker wrote:
private(this) int y;
This keeps the implementation simple and the scope focused.
Yeah, maybe more focused at the beginning would be better. A
comma separated list can be added later if deemed worthy.
And agreed, the java recommendation might help build a case.
There's also the argument of avoiding state related bugs in
larger code bases that is managed through computed properties:
class A {
@property int i() {
// fix internal state due to access
return _i;
}
private int _i;
}
Of course these are all solved by putting a class in its own
module anyway. I can see this being problematic the bigger code
bases get though. I.e. programmer A adds an extension function in
module M that is 6000 lines long and doesn't see that he should
do A.i and not A._i - bug maybe goes unnoticed for long time.
Only thing I can actually think of is if you want to have
extension functions on classes in the same module and only want
some variables to be accessible from extension functions but keep
other truly private, you can't do this. So it makes writing code
in an extension based style harder. But then you can argue if an
extension needs to access private(this) variables then it should
be module private anyway. So meh...
