On Thursday, 17 May 2018 at 10:34:18 UTC, Zoadian wrote:
On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:
I propose an idea, for discussion (robust discussion even
better ;-)
Add an new attribute to class, named 'sealed'.
If class level protection is added, please do not call it
sealed.
People from c++ might be suprised by 'private' already. We do
not have to confuse those c#ies too.
Interesting.
If only D had applied that same criteria to use of the word
'private'.
I do wonder what word could possibly suffice, to please everyone.
Module level protection is enough to hide implementation
details though. So while i do understand why you want this in
D, i don't think it is worth it to complicate the language for
something you can work around easily by putting the classes in
their own modules.
Here, I think you are falling into the trap, of believing, that
the concept of
modularity can only ever apply the way D currently applies it -
at the file level.
In OOP programming, the class is the module. (yes, I know how
much D programmers love OOP ;-)
When OOP programmers come to D however, they are 'forced' into
the D concept of modularity, and cannot model modularity in
accordance with their own problem domain - but have no choice to
use one class per file - just to regain what they already have in
other mainstream languages. But then, for those OOP programmer,
the 'file' has little value, cause it now can only ever represent
a single class.
Remember, that the idea here is not to force anyone to change how
they currently think or do things. It simply extends the way in
which a 'file' module can be used.
I'm also not convinced think that your 'sealed' would be used
much, because accessing private state in the module is actually
extremly useful (e.g. unittests).
Again, what people can do, they will still be able to do. Nothing
changes for them.
btw. D has less than 1000 programmers. How many OOP programmers
in the world?
Build it, and they will come...perhaps.
That beeing said, if you are convinced it would be a good
addition, please write a DIP.
DIP before discussion, is not the way I do things.
Even if it will not be accepted it will at least force a
decision. And we can point to the reasons it got
accepted/rejected in the future.
Again, DIP before discussion, and we all know what will happed to
the DIP.
