Adding a new design constraint to D

JG someone at somewhere.com
Tue Jun 14 07:05:14 UTC 2022


On Tuesday, 14 June 2022 at 06:43:36 UTC, forkit wrote:
> 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??

So there is no use case for "friend class" in C++?
>
>> 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.
>

Isn't that a bit of a weak answer? Couldn't anybody proposing
a feature they want answer the same way?

>
>> 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.


If what you say were true, couldn't we say that from now on 
putting
a class alone in a module shows the intent of making private mean
private to the class?



More information about the Digitalmars-d mailing list