Feedback on Átila's Vision for D
Nicholas Wilson
iamthewilsonator at hotmail.com
Sun Oct 20 01:52:01 UTC 2019
On Saturday, 19 October 2019 at 23:38:51 UTC, aliak wrote:
> On Saturday, 19 October 2019 at 17:27:26 UTC, Nicholas Wilson
>> 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.
What I'm saying is a boundary point exists, even if is not
precisely defined, passed which point separating your module into
a package is a win for readability and reasonability.
> Plus, IIRC dmd is a prime example where splitting is not
> happening because of "reasons". So it's not always doable
> either.
Those reasons are largely "Walter" and are unrelated.
> 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.
Indeed, no need for "friend".
> 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?
Because that doesn't allow you to do anything fundamentally new,
as in the above solutions _work_, even if they don't work as well
as you'd like them to, and to me it serves as a marker that if
you are running into that problem then you module is too large
anyway you likely have other issues regarding trying to reason
about the code.
No I haven't used both at the same time, but I've used them
separately and I find that module private provides enough
encapsulation that I don't find myself wanting something more (As
opposed to C++ where this impossible because there is only
textual inclusion, not symbolic imports).
More information about the Digitalmars-d
mailing list