On Thursday, 16 February 2023 at 02:26:44 UTC, Mike Parker wrote:
On Wednesday, 15 February 2023 at 20:10:31 UTC, ProtectAndHide
wrote:
What Mike is arguing, is that I don't need a 'data hiding'
mechanism for a user-defined type, because that is already
provided to me by the 'data hiding' mechanism of the module.
That is his argument.
My argument is that I want 'data hiding' mechanism at the
user-defined type level as well.
Again, his argument is that i don't need it.. because...
Wrong. I'm arguing things:
1. D has encapsulation (you say it doesn't).
2. We don't need a new protection attribute or a redefinition
of private because D already provides the mechanism to give you
what you want.
Honestly. How hard is it for you to accept? It's so simple I
could explain it to first year programmer!
It's really straight forward, obvious, correct, and can be
demonstrated like this:
// foo type has no ability (at the type level)
// to hide anything from other code in the module.
// this is fact. I'm not making it up!
// There is nothing to argue against here. It's just fact.
module test;
@safe:
import std;
class foo { private int x = 10; } // C++, C#, Swift,
Javascript...programmers - beware!
void main()
{
foo f = new foo;
f.x = 20; // D provides no way to prevent this from occuring
as there is no mechanism at the type level to do this. Instead
you have to put foo in a module by itself, so no other code can
access x. So EVERY user-defined type that wants data hiding from
users of that type (including other code in the module using that
type), must be in its own module.
writeln(f.x);
}
I understand your argument completely. Just put foo in its own
module. I get it.
What you don't get, is that I want such design decisions to be in
my hands, and not yours.
That is, I want a mechanism at the type level as well.
You don't want me to have that. Well fine.
But at stop mispresenting what I'm saying. What I've stated
above, is what I'm saying.. no more.. no less.
