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?)
