On Thursday, 16 June 2022 at 09:54:48 UTC, Olivier Pisano wrote:
> On Thursday, 16 June 2022 at 08:55:52 UTC, forkit wrote:
>> On Thursday, 16 June 2022 at 08:51:26 UTC, Olivier Pisano wrote:
>>>
>>> Yes, every once in a while we get such discussions when someone finds out that D doesn't work exactly like [insert one's favorite language here] and pretends that is THE cause of the lack of popularity of D.
>>>
>>
>> [insert one's favorite language here]
>>
>> like this you mean:
>>
>> [some of the most popular and widely used languages in the world]
>
> Which doesn't mean it would fit in D and play well with other D features.
>
> Especially since everyone has different favorite.

My point is, either it supports one of the most important aspects I've worked with in OOP over 20 years, or it doesn't.

i.e. it doesn't.

would be nice if it did - 'if' it could fit in the language and work well with other things.

are you suggesting i want it in the language, no matter what the cost is?

On Thursday, 16 June 2022 at 08:58:09 UTC, forkit wrote:
> On Thursday, 16 June 2022 at 07:45:52 UTC, Kagamin wrote:
>>
>> ..
>> Also memoization is a use case for varying access between different methods of the same class. Would you address that too?
>
> I got no idea what that is all about.
>
> I just want to make a private variable in my class, private to the class ;-)

When you have a lazily initialized field, you need to use an accessor, because if you read the raw field, you get an uninitialized value and error as a result, so only the accessor should have access to the field.

On Thursday, 16 June 2022 at 09:54:48 UTC, Olivier Pisano wrote:
>
> Which doesn't mean it would fit in D and play well with other D features.
>
> Especially since everyone has different favorite.

fair enough. eveyone has there favoutite language, and their favourite style, and their favourite this.. and that...

this feature request (discussion) is not about a 'favourite' anything.

this is about a core principle in OOP.

all of us ask the question 'does this need to be exposed to others'.

well, I sure hope that's a question on your mind, when your programming.

if it's not, you should not be programming.

In OOP we ask this question all the time. More than most other paradigms, I'd suggest.

I think the people complaing about this, either don't get this, or they're anti OOP (and don't tell me they don't exist in the D community ;-)  ...

The only real question on peoples mind, should be ->  if we allow a class to have private members (to the class), how will this fit in and affect the rest of the language (technically).

at this stage, not a single person has bothered to even make an attempt to explore an answer to this question.

On Thursday, 16 June 2022 at 11:26:23 UTC, forkit wrote:
>
> at this stage, not a single person has bothered to even make an attempt to explore an answer to this question.

except maybe Kagamin ;-)

On Thursday, 16 June 2022 at 08:55:52 UTC, forkit wrote:
> On Thursday, 16 June 2022 at 08:51:26 UTC, Olivier Pisano wrote:
>>
>> Yes, every once in a while we get such discussions when someone finds out that D doesn't work exactly like [insert one's favorite language here] and pretends that is THE cause of the lack of popularity of D.
>>
>
> [insert one's favorite language here]
>
> like this you mean:
>
> [some of the most popular and widely used languages in the world]

The D design is from Java, a popular and widely used language.

On Thursday, 16 June 2022 at 11:31:48 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 16 June 2022 at 11:26:23 UTC, forkit wrote:
>> The only real question on peoples mind, should be ->  if we allow a class to have private members (to the class), how will this fit in and affect the rest of the language (technically).
>>
>> at this stage, not a single person has bothered to even make an attempt to explore an answer to this question.
>
> I think I have, but I can do it again:
>
> Since D has meta programming capabilities it can affect meta programming code that makes assumptions about access control modes being fixed to the existing set.
>
> As such it will be a breaking change, but will probably not break most programs.
>
> (Basically all changes that go beyond syntax sugar are breaking changes in D.)

ok, except you too ;-)

I must have missed this in all the nonsense going on...

the constraint is optional, just as using meta programming is optional.

but if the D language requires that 'meta programming in D must be able to access class members that are private to the scope of the class', then assuming this would not be the case if the suggestion were implemented, then we have a first, genuine, issue to consider  ;-)

On Thursday, 16 June 2022 at 11:36:15 UTC, Kagamin wrote:
>
> The D design is from Java, a popular and widely used language.

well, i don't know from where the idea popped into Walters head actually came from... but pretty sure the module concept came well before Java arrived on the scene ;-)

On Thursday, 16 June 2022 at 11:10:33 UTC, Kagamin wrote:
> On Thursday, 16 June 2022 at 08:58:09 UTC, forkit wrote:
>> On Thursday, 16 June 2022 at 07:45:52 UTC, Kagamin wrote:
>>>
>>> ..
>>> Also memoization is a use case for varying access between different methods of the same class. Would you address that too?
>>
>> I got no idea what that is all about.
>>
>> I just want to make a private variable in my class, private to the class ;-)
>
> When you have a lazily initialized field, you need to use an accessor, because if you read the raw field, you get an uninitialized value and error as a result, so only the accessor should have access to the field.

as this is a little over my head, I think, I'll answer it this way.

if you can memoize now in D, you can still memoize if this idea were implemented.

I'm happy to be corrected here.