Adding a new design constraint to D

forkit forkit at gmail.com
Tue Jun 14 06:43:36 UTC 2022


On Tuesday, 14 June 2022 at 06:09:57 UTC, JG wrote:
>
> I think you are missing part of your analysis. Is this a 
> complete feature you are suggesting to be added? I also haven't 
> thought it through to the end but for instance wouldn't 
> something like "friend" need to be added shortly after adding 
> this?
>

No. I cannot see how such a concept (of needing to add friend) 
would ever apply here??

> Another point that you are perhaps missing is that each person 
> who uses D probably has at least one thing they would like 
> added to the language (which they consider to be extremely 
> important). If all these things were added, D would be much 
> more complicated than it is now, even if each is a minor change.
>

This may be a valid reason for not adding 'any' new feature, but 
it is not a valid reason for not adding 'this' feature.


> In reading what you wrote I didn't find the following clear:
>
>> However, the one-class-per-module approach, imposes its own 
>> new design constraint, and not one the programmer necessarily 
>> makes of his/her own volition.
>
>
>> It also does not necessarily follow, that a class in its own 
>> module, is there for the purposes of stipulating this 
>> constraint.

Putting one class in a module by itself, means no other code 
except that class is in that module, and therefore the class does 
not need to 'hide' anything from any other code in the module - 
cause there isn't any other code in the module.

But putting one class in a module by itself, demonstrates no 
intent whatsoever.

You have to ask the designer why they chose to do that.

The option suggested would 'explicately' specify an intent, and 
can do so *without* enforcing a one-class-per-module design 
constraint onto the programmer.






More information about the Digitalmars-d mailing list