Using closure in function scope to make "real" private class members (page 14)

On Wednesday, 8 June 2022 at 06:56:50 UTC, Walter Bright wrote: > > The unit of encapsulation in D is the module, not the class. Why is it less of an abomination? Class is the unit of encapsulation by the very definition of OOP. D just forces you into the class-per-module paradigm, basically redefining modules as classes. That is just as abominable, given friends are rare in "properly" designed OOP code.

On Wednesday, 8 June 2022 at 08:11:41 UTC, Dom Disc wrote:

look for all friends in the whole project. I personally hate it if I should review a file and then need to look into dozends of other files to do this. And C++ tend to always require this. One of my main reasons to drop C++.

I think many such issues actually are tooling issues and architecture issues just as much as language issues.

It is very difficult to talk of C++ being this or that since the language itself doesn't impose much structure. You can have a good or bad structure, and it really comes down to modelling, design patterns, software architecture choices and discipline.

Other languages impose more firm structure and that can be good, or bad, depending on what you try to achieve, but you can also use tooling to establish a structure so…

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.

On Wednesday, 8 June 2022 at 08:23:31 UTC, Max Samukha wrote: > That is just as abominable, given friends are rare in "properly" designed OOP code. Not in C++. E.g. operator overloads with the class as second operand but some basic type as first operand _can't_ be member functions (because C++ doesn't have op_right). But operators tend to really need access to the innards, so most of the time they have to be friends. And there are many operators, hence many friends...

June 08, 2022

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

Posted by forkit
in reply to Ola Fosheim Grøstad

Permalink

forkit

Posted in reply to Ola Fosheim Grøstad

Permalink

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.

Forums