Feedback on Átila's Vision for D
something at something.com
Sat Oct 19 23:38:51 UTC 2019
On Saturday, 19 October 2019 at 17:27:26 UTC, Nicholas Wilson
> On Saturday, 19 October 2019 at 13:45:37 UTC, Aliak wrote:
>> On Saturday, 19 October 2019 at 12:23:36 UTC, Nicholas Wilson
>>> 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.
>> 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
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?
More information about the Digitalmars-d