Wed Oct 17 - Avoiding Code Smells by Walter Bright

[TheFireFighter]

On Wednesday, 7 November 2018 at 13:15:03 UTC, Dennis wrote:
>
> If you can't show that there are actual programmers writing 
> appropriately sized modules containg bugs simply because of the 
> lack of a class-private visibility level, then people don't 
> want to engineer a solution to a seemingly non-existant 
> problem, write and maintain the compiler code + specification 
> for it, update existing tutorials, editors and tools, inform 
> existing users about the change, and making the language more 
> complex overall.
>

well you could say the same about pointers. but..what happens 
when a large number of programmers start using pointers?

In the hands of few, it's not such a big issue.

In the hands of the many, well.. we all know the result. Decades 
of bugs!

Should we wait till the bugs start appearing?

But my argument actually is less about bugs, or the potential for 
bugs (although that potential obviously exists). My argument is 
more about the 'untyped' nature of the D module. That is, a type 
(say a class) is 'naked' in a module, exposed for all (in that 
module) to see. It can be violated in any number of ways, by 
other code in the module. I mean that is just fact. It's not 
something I should need to continually point out.

Some say that' fine. A class should be subjected to that 
humiliation.

Other say, if you wan't to prevent that humiliation, then you can 
do it already - that is, you can clothe a class, in D, by 
'walling it off' in it's *own* module.

That immediately tells you something about the nature of the 
module. The module is essentially an untyped universe. It removes 
the clothes from the class, and allows it to be violated. On that 
basis, bugs (or the potential for them), becomes an immediate 
reality - and more so in the hands of the many, as opposed to the 
hands fo the few.

Now, if you're one of those that object to the use of classes 
(and there are many in the D forums), then you would already be 
biased towards dismissing my argument, and don't mind at all if 
the class is subject to humiliation. I would prefer you refrain 
from the discussion, if such bias is going to be used to shutdown 
the argument. Because it just brings the tone of the discussion 
down to a level that nobody wants to participate in - likely it's 
goal in the first place.

Lets be clear. My argument (not my DIP - as there is none) is, 
that it can only strengthen D, if D allowed the programmer the 
option (just the option) to ensure that a class wasn't subjected 
to such humiliation, when there is other code in the module 
besides that class.

The major purpose of a class afterall (understood by most 
programmers), is to impose contraints on interactions with other 
objects (or other code), in order to enforce correctness and 
eliminate inconsistencies. It does this, by clothing itself, so 
that other types cannot operate directly on its naked 
representation.

Yes, I know, you *can* clothe your class in D, but *only* if you 
wall it off in it's module. If you want 2 classes in your module, 
now you need to manage 2 classes across 2 different modules. That 
is an increase in complexity for the programmer.

But you have no choice, because the very instance you put other 
code in that module, you remove that protective clothing.

All I'm asking for, is the ability to have extra code in the 
module, without the module removing the clothes from my types.

Is that really too much too ask?

I do not understand the motivations of those that reject such an 
argument.

(hopefully, the moderator will post this..you never know on these 
forums..peoples post are going missing, or show up in the wrong 
order, days later....what's going on?)