Adding a new design constraint to D

[forkit]

On Thursday, 16 June 2022 at 07:45:52 UTC, Kagamin wrote:
> On Thursday, 16 June 2022 at 00:02:41 UTC, forkit wrote:
>> Sean L. Palmer : "I find that it's one of the biggest pains in 
>> programming, deciding what to make private, what to 
>> encapsulate, what to expose."
>
> Incapsulation is overrated, so it's really a non issue, maybe 
> only if you treat incapsulation as a superidea, but D doesn't 
> honor superideas, it's a practical language.
>
> Also memoization is a use case for varying access between 
> different methods of the same class. Would you address that too?

'encapsulation' is an abstract concept.

It may well be overrated, but that doesn't mean it's not useful, 
and sometimes necessary. Without it, we humans would have a hard 
time understanding anything, about anything. It's an vital 
component of how we understand things. (yes, I have psych degree 
;-)

The old OOP ideals of "all member variables should be private" 
and "global variables should be avoided", have clearly not been 
the best choice, over time, and certainly should never apply by 
default, for all cases.

What's important, is the designer(programmer, programming team) 
have the options to strategically use this principles to 
accomodate the design they believe is best for them.

This is particulary important when doing OOP, which is very 
different to the C like procedural progammning you often find in 
the D community. That C like mentality, I believe, is the source 
of the module design in D (i.e. everything global to the module, 
and that's all there is too it).

Fortunately, Swift (which intenationally set out to drop all the 
baggage that came with C and C like thinking), 'seems' (I've only 
been using it a couple of days), like a very nice alternative to 
D, for me - not just because it returns that choice to me, but 
the syntax is very pleasing to understand and work with (one of 
D's biggest advantages too).

With the options available to me in Swift, I feel 100% 
comfortable in programming in the large. Not so in D.

Although I program mostly in C#, so I've never been restricted to 
programming in the small ;-)

But in the many years I've been 'playing' with D, I've never 
considered it a suitable language, for me, to program in the 
large - primarily because of the 'everything is global in the 
module, and we in D, don't want you to have any other choice in 
this'.. .thing.