On Sunday, 21 October 2018 at 19:53:35 UTC, Jonathan M Davis
wrote:
On Saturday, October 20, 2018 9:17:23 PM MDT 12345swordy via
Digitalmars-d wrote:
So that classes can share some of their variables but not
others in a module.
IE.
class A
{
internal int A; //This is shared in the module
private int B; // But not this.
}
No need to reintroduce the "Friend" feature from cpp.
Well, if you feel strongly enough about it, you can always
create a DIP to try to change things, but I think that I can
quite safely say that you have pretty much no chance of it
getting accepted. Walter has been quite clear on this topic
when it has been discussed previously (and there was a major
discussion on it not very long ago). It is very much on purpose
that access is controlled at the module level, and if your
module is large enough that it is actually causing problems for
a class or struct to not be able to disallow access of its
members to other symbols in the module, then the module is too
large, and the class should be put in a separate module. We
already have full control of who can access the members of a
class or struct by controlling which module or package its in
and what else is in that module or package with it. If you want
greater control without splitting up your modules more (at
least as far as importing goes), you can always take advantage
of public imports to split the code itself into more modules
while making it possible to get all of the symbols with a
single import statement.
Certainly, if we had internal or friend or other mechanisms for
more fine-grained control without doing it at the module-level,
it would eliminate the need to put code into separate modules
in some cases, but it would also complicate the language, and
what we have works quite well in general.
If you don't like the fact that member access is done at the
module level, then I'm sorry, but overall, this really seems to
be a philosphical complaint and not a practical one, and Walter
has made his stance on it very clear. Based on what he's said
previously, you would need very strong, practical arguments for
why it's causing actual bugs in programs and why the current
approach is not cutting it to stand any chance of convincing
Walter. And honestly, I have never seen anyone come up with an
argument that was particularly good in that regard. It mostly
seems to come down to folks simply objecting to the idea that
anything inside a module would have access to a class' private
members rather than that it's actually caused bugs. In
practice, it's usually either actually useful, or it doesn't
matter.
Either way, simply making post stating that you think that we
should have the feature isn't going to get you anywhere. If you
want it, you'll need to find a way to convince Walter.
- Jonathan M Davis
I do plan to write a DIP on this, no question about it. However
walter have been shown to change his mind unexpectedly. (Remember
the "mangle symbol only" discussion that manu had argue in favor
of, which we all thought he sternly opposed to, only to changed
his mind at the last minute, when a pull request shown up?)
Yes I am aware of the previous discussion regarding this. How can
I forget about it as that guy who complain about it resort to
imposter other people including me.
https://forum.dlang.org/thread/vpxoidaqfbfrnnsep...@forum.dlang.org?page=1
However that guy didn't property explain why this was an issue.
The issue is encapsulation and the traditional get and set
functions for security checking and value checking, etc, before
setting the value, retrieving the value and after setting the
value. Programmers such my self sometimes find it easier to
maintain classes if they are put in the same file, rather than in
each own file.
The "package" solution brought up by another user risk the
possibility of making things more complicated and harder to
maintain than it should be, when working with code that is
considerably small spread across multiple files.
I have two solutions in mind:
A.)Introduce the keyword "strict" for the other keywords private
and protected only class and structs to prevent being accessed
from outside the class in the same module by accident.
Example:
class A
{
strict private int x;// This can't be shared in module
strict protected int y; //ditto
private int x; //This can be shared in module
protected int y; //ditto
}
B.)Get rid of the "one module per file" restriction by
introducing optional module scoping to allow multiple modules in
a file to allow easy package creation for code that is consider
to be small without having to maintain multiple files.
Module C;
Module A // Module A in the C package
{
}
module B // AKA B.A
{
}
-Alex
