Using closure in function scope to make "real" private class members
Ola Fosheim Grøstad
ola.fosheim.grostad at gmail.com
Tue Jun 7 14:04:27 UTC 2022
On Tuesday, 7 June 2022 at 12:47:36 UTC, forkit wrote:
> I disagree with your assertions here. I don't think you've
> fully grasped the benefits of encapsulation in terms of
> decomoposition.
Hi, the benfits of encapsulation is obvious, but you can
encapsulate without having language support. If you want
class-private, just choose the convention that "_fieldname" means
class-private. Every time you see "obj._fieldname" you will
realize that this is not what you want to do. If that is not
enough, use static analysis.
The reality is, encapsulation does not have to be in the language
at all in order for you to have encapsulation. It can be a mental
thing/code review thing, it can be a grammar thing, it can be a
linter issue.
Python does not provide in-language encapsulation at all. Yet I
encapsulate my classes in Python all the time. And I have
external tools to check for it if I want.
Beta did not provide in-language encapsulation at all, but the
fragment system for source code composistion did.
This aspect of D does not limit you as a programmer. Memory
management issues do, however. How about focusing on stuff that
truly matters and that is likely to change?
> D 'insists' on not giving you the means to protect that
> encapsulation. D just does not have the language construct to
> do that - intentionaly, by design even!
There are lots of things D insists on, and this is the least
problematic one… How about focusing on things that you cannot fix
yourself with an external tool?
If this was to change then the only sensible thing would be to
adopt what is common in other languages, but allow "protected"
access to module members. This is unlikely to happen, and the
last thing D needs is more @noise in the syntax. So the least
problematic choice is to keep it as is.
> The simple fact is, that a class in D is a weak type, since
> violations of its contract from other code in the module,
> cannot be detected during compilation.
All C derivatives have weak type systems across the board.
More information about the Digitalmars-d
mailing list