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.

Reply via email to