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