Wed Oct 17 - Avoiding Code Smells by Walter Bright

TheFireFighter TheFireFighter at gmail.com
Thu Nov 8 23:50:18 UTC 2018


On Thursday, 8 November 2018 at 13:18:30 UTC, Dennis wrote:
>
> That sounds like "I just want there to be the option for 
> aggregate value types... without using struct.". The question 
> this raises is why the current solution is so problematic.
>

I just want (for example) to be able to write a module, that 
contains a class, and also has non-member, non-friend functions.

You simply cannot do that in a D module, as the class has no 
clothes - to extend the metaphor from my recent post.

I refer you to Scott Meyers article about the benefits of having 
'non-friend' non-member functions:

How Non-Member Functions Improve Encapsulation (btw. people 
misread that title - it should be been "How Non-Friend, 
Non-Member..."

http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197?pgno=1


>
> Do you agree that language additions add a lot of weight? If 
> yes, then it's simply the fact that people don't think your 
> suggestion bears that weight because it's already possible to 
> do what you want in another way.

No it is not. You can keep saying there is, but it doesn't make 
it so.

We don't seem to be on the same page here...do you misunderstand 
what I want?

Fact: I cannot have a class in a module, and specify (so that the 
compiler can enforce it) that I want other code in the module to 
respect the specification of that class. It just cannot happen. 
Don't say it can. It can't. It's fact.

As a result, one of my core guidelines are not applicable 
anymore, if I used D:

" Don’t force together into a module things that will be used or 
maintained separately, and don’t separate things that will always 
be used and maintained together."

Regarding the 'burden' to the D langauge, by providing the 
programmer with a tool to specify better encapsulation of code 
*within* the module:

"I have become more and more convinced that the key to code 
reusability and scalability is encapsulation — having subsystems 
communicate through small, well-defined interfaces and letting 
them hide their own implementation details."
- Walter Bright

http://www.drdobbs.com/cpp/uniform-function-call-syntax/232700394?queryText=Scott%2BMeyers

i.e. better encapsulation really is a good thing (although for 
many, it a lesson that needs to be learned).




More information about the Digitalmars-d-announce mailing list