munificent
commented
4 years ago Complete member access disallowance might not be the best way to deal with it, this could be dealt with on a higher abstraction layer than the language itself.
That has real practical negative consequences. Let's say you maintain a package foo, that has a class Foo:
class Foo {
// Stuff...
}A user of your package has a class Bar:
class Bar {
int _privateField;
}Everything is working fine. Later, you decide to make a change to Foo that is purely an implementation detail and should affect no users:
class Foo {
String _privateField;
// Other stuff...
}This works fine today. Maintainers of packages can add and remove private fields confident that they will not harm their users. If privacy is no part of the language, then from the language's perspective Bar._privateField would now be an erroneous override of Foo._privateField and the code would have a compile time error. This is why, for example, Python name mangles members that start with a double underscore.
The confusion can easily be avoided by making clear private access is an “advanced” or “dev” feature which should be avoided unless it is really understood what is being done and making it clumsy to access it (for example requiring special keyword or enabling a special mode in the pubspec).
Library authors can accomplish this now using naming and multiple libraries. It's fairly easy to separate out advanced members just by doing good API design.
I believe there should always be as much freedom as possible, because this allows exploration and creativity to express.
You are only thinking about the freedom of the consumer of a library. But what of the freedom of the maintainer of the library? Privacy gives maintainers freedom because it gives them more safe space where they can change their library while being confident that they do not break users. That freedom in turn benefits consumers because it makes it easier and faster for maintainers to evolve their libraries and provide new functionality to users.
All in all, what I try to say is that I would not disregard any feature request, because if someone asked for it, it is because it expresses something that at some point they would have liked to have.
I didn't close the original issue by discarding it out of hand. Dart is almost ten years old. We have had this discussion around privacy — including exactly the arguments of how it interacts with personal freedom — many many times over the years. The point that we've arrived at is based on careful deliberation. All encapsulation features in a language make trade-offs between what the consumer and maintainer of a library are allowed to do. There is no silver bullet that gives total freedom to both sides.
The point we've chosen closely follows most other object-oriented languages and seems to strike a decent balance.
Note that Dart, unlike Java, C++, and C# gives consumers an important affordance. Packages are distributed as source. If a consumer wants to do something unsupported, they can always copy the library and edit the source themselves. Given that, I see little upside to taking flexibility away from package maintainers. It is already hard enough to change a class in Dart without potentially breaking users as it is.
icatalud
lrhn
rrousselGit
leafpetersen
I posted #409 some time ago, but it got rapidly closed. This has been a permanent annoying issue for me so I came back to revise the post and the arguments given and I would like to raise this issue again, hoping that this time it remains open for further discussion and/or for future reference for people that might also want this feature, unless there is a conclusive argument that completely closes the door. The arguments I could gather to justify disallowing private member access are the following:
In my case, I had to permanently spend time, find work arounds and comprise the best design in order to deal with the impossibility to access private members. At the very least I would have liked to easily access them to code a prototype solution (get excited about it) and then think about how to make it possible without private access. Particularly in Flutter I have permanently desired to access the _child or _dirty field in Element (examples that I can remember right now). I do not think those fields are ever going to be changed, they are hidden mainly because accessing them makes no sense in the common Flutter app, it would only cause confusion and if they get overridden it could break the Framework proper flow.
Proposal
Option 1: Allow accessing private members only through a keyword “private NameOfSuperClass _nameOfPrivateVariable” and explicitly discouraging the use of private unless strictly needed in the language guide or through dart analyzer default warnings (forcing ignore warning comment) to avoid using this. Similarly it should be possible to instantiate and access private classes using private _NameOfPrivateClass.
Option 2: Allow access to all private members from a certain import by adding a special keyword like "import private ..." or "import dev ...". There is still the problem with conflicting private member names of ancestor classes, but then the private member could be accessed by prefixing the name of the class like in Option 1.
Personal philosophy about freedom
I believe there should always be as much freedom as possible, because this allows exploration and creativity to express. Creativity is by definition something new and unexpected, therefore it cannot be predicted, if it could be predicted then it would not be creative. Absolute freedom can of course be harmful, so under what justifications should be freedom be contained (IMO)?
Programming language freedom
In a programming language there is no direct obvious risk to harm anyone with freedom like there could be with a physical object. Playing with code is a harmless sandbox (one of the beautiful things of writing code), so in my opinion a language should allow to play with it within all the imaginable possibilities even if it seems useless or inconsistent. For example I would like that in Java it was possible to access internals which do not seem useful and is not consistent, like reading or setting reference pointers. Some might use their creativity to make something interesting, but not necessarily useful in a direct productive way. For example, art or entertainment are not directly useful-productive, but they probably have an indirect impact on it. To prevent rare features to cause disorganization or confusion, all that is required is to be crystal clear that those are advanced features and/or put barriers to use them, so that only “advanced” users reach them. For example I would enable all kind of weird things in a special "dev mode" that can be activated either in the pubspec or in the dart file. The language guide should direct a common proven productive programming pattern.
All in all, what I try to say is that I would not disregard any feature request, because if someone asked for it, it is because it expresses something that at some point they would have liked to have. Features that are decided are not worth to be put on the language should at least be allowed to become experimental (they hardly harm someone over there). Which features are chosen to be developed should be based on the developer’s preference. Usually the most requested features are the most likely to be developed first, that is a natural gradient of where humans put their interest.
I understand that this might not be highly requested, however if I get interested, I could even personally attempt to implement this, I would just like to hear opinions about the possibilities and the best semantic approach.