Using closure in function scope to make "real" private class members

[forkit]

On Wednesday, 8 June 2022 at 08:36:10 UTC, Ola Fosheim Grøstad 
wrote:
>
> Is the language dominating the strucuture?
>
> Or is the structure a result of the culture of the people using 
> it?
>
> Most of the time it is the latter, it is the culture and the 
> people.

In D, it's certainly the language that is dominating the 
structure here.

4 facts:

(1) A class is THE 'central' notion to OO programming.

(2) A class implements a type.

(3) The OO features in D, all come from the class.

(4) In D, classes are (also) programmer defined types.

A module should not have ownership over the specification of a 
type. That ownership should belong to the person writing that 
specification. It's the language that is enforcing a different 
structure (in terms of OO design) here.

Fine. D has decided that module will make the decision, by making 
everthing within a module a friend of any type declared within 
that module. If this was a design decision because of the 
problems of 'friend' in C++, fine. That makes sense. I get it. 
But does it really make sense that you cannot unfriend? This 
should be a decision the programmer at least has the 'option' of 
making.

In my 'perfect world' view of D, the module should only have 
ownership of 'the aggregation' of the related abstractions that 
are contained within it, thus providing a nice barrier to the 
outside world for that 'aggregation'.

When the module owns the specifications of all the abstractions 
contained within it, there are consequences. How can type 
conformance be enforced within a module? It can't. Imagine if I 
could, accidently, willy nilly, put a "wtf!" into an int, and not 
even know about it, till it was too late.

Walter has his firm view. I have mine.