| |
| Posted by forkit in reply to JG | PermalinkReply |
|
forkit
| On Tuesday, 14 June 2022 at 07:05:14 UTC, JG wrote:
> 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++?
My point is, there is no problem making friends in D, cause everyone is already your friend - you got no choice anyway - that's how it is, full stop.
the problem is in the unfriending part.
if you take this too the extreme, as some no doubt will, the argument will be 'well if they're not friends then why put them in the same module?'.
but that's a strawman argument - which results from taking the point to the extreme.
I'm about friends that can have the capacity to keep some part of their existence to themselves, and under their control.
this is what D lacks.
friends are defined by their ability to mutate every aspect of each other.
However, in D they are (cause it lacks this feature I'm suggesting).
>
>>> 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?
>
To understand the downside of implementing this particular feature, I need to know arguments specific to this feature.
Arguments that can be applied to any feature are not relevant, in this context, that is what I'm saying here.
The argument put forward relates to 'change' in general. Not this feature, specifically.
>>
>>> 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?
any convention can be used to indicate intent.
I don't wont to indicate intent.
I want to explicately state intent. I want the compiler to enforce that intent.
I want anyone reading my code, to immediately understand my intent, and not rely on them understanding my 'conventions'.
|