Feedback on Átila's Vision for D

[aliak]

On Saturday, 19 October 2019 at 17:27:26 UTC, Nicholas Wilson 
wrote:
> On Saturday, 19 October 2019 at 13:45:37 UTC, Aliak wrote:
>> On Saturday, 19 October 2019 at 12:23:36 UTC, Nicholas Wilson 
>> wrote:
>>> IME, no. If your module is big enough that you can't keep all 
>>> of it in you head and you start calling implementation 
>>> details of your classes _by accident_ then either:
>>> a) name your implementation details so they stand out so you 
>>> don't call by accident (e.g. a._something() )
>>> b) split up your module into a package so that it fits in 
>>> your head, this will (probably) cause you to not be able to 
>>> call the implementation details at all, and will thus cause 
>>> you to have to think about the organisation of you package 
>>> (which is probably a good thing).
>>
>> Solution a is a convention.
>
> Indeed.
>
>> And solution b is fluffy.
>
> How so? Also, you should probably be doing that anyway for 
> different reasons.

As in "fits in your head" is not concrete. And it's usually not 
just "you" in a team. Plus, IIRC dmd is a prime example where 
splitting is not happening because of "reasons". So it's not 
always doable either.

Furthermore, neither solution allows you to completely 
encapsulate some vars in a type while allowing module functions 
to access others that are not accessible outside the module.

>
> Since I don't expect to convince you of anything further, the 
> only thing I can suggest is to write a lint rule using the 
> compiler as a library (or hack the compiler yourself), since 
> changing the behaviour would almost certainly be rejected on 
> cost (i.e. breaking stuff) / benefit, and adding a second 
> private would probably also be rejected as too narrow a feature 
> for marginal, at best, utility.
>
> I can't remember if you do compiler stuff, but I'd be happy to 
> help once I have some time (or try slack for faster response 
> from others).

Well, the problem is that I've used languages with moduleprivate 
and privateprivate and it's from experience that it's cleaner. So 
unless there're some actual disadvantages to having that extra 
granularity that I'm not seeing, I suppose there can't be any 
convincing (and really, I was just trying to point out that the 
notion that D's access levels are obviously the correct ones is 
arguable, therefore not obviously correct - re Mike's post)

And thank you :) appreciate the offer! But it's not something I 
care too much about. And to get something like this in I'd have 
to argue for why encapsulation of user defined types is a good 
thing. A if I actually have to argue for that, pretty sure it 
won't go anywhere. So it's just a level of access I accept is 
missing from D - one good thing about it is that it gives you 
less choice so you don't need to worry about privateprivate vs 
moduleprivate.

But anyway, curious, why do you think it's of marginal utility at 
best? And on a related note have you used any languages that 
provide both levels of granularity that I mention above?