Time to destroy Walter: breaking modules into packages

[Jonathan M Davis]

On Thursday, June 20, 2013 05:39:30 TommiT wrote:
> On Wednesday, 19 June 2013 at 22:40:47 UTC, Jonathan M Davis
> 
> wrote:
> > On Thursday, June 20, 2013 00:21:45 TommiT wrote:
> >> Also, I'm just curious why do you keep saying "we don't want to
> >> complicate the package access specifier any further"? Because
> >> isn't the current specification of the package access specifier
> >> the simplest possible that it could ever be? "Everything under
> >> the same folder has access to symbols labeled package". It
> >> takes
> >> just 11 words to define it. You're talking about it like it's
> >> already somehow complicated.
> > 
> > No, it's not complicated, but the lanugage as a whole is
> > complicated, and any
> > new feature that's added to it increases its complexity. As
> > such, it needs to
> > pull its weight, and I really don't believe that that's the
> > case here. I just
> > don't think that complicating the package access modifier any
> > further is worth
> > the gain. There is some gain, but I think that it's ultimately
> > quite small,
> > and I'd much prefer that access modifiers stay simple.
> > Obviously, you're
> > entitled to think that the extra complexity is worth it, but I
> > don't agree.
> > 
> > - Jonathan M Davis
> 
> You're willing to add extra complexity and inconvenience to
> programming in D just in order to keep the language specification
> simple. I don't think it's a good trade-off. Learning the complex
> details of language is a one-time cost that all programmers must
> pay when they start with the language. Whereas complexity and
> inconvenience in actually programming with the language is a
> running cost and may be a source of bugs as well. The running
> cost should clearly over-weight the one-time cost here.

I don't think that this adds much complication to programs, because I don't 
think that the sorts of problems that you're worried about when refactoring 
code are likely to be common, and they can be gotten around by reworking how 
your code is designed. Worst case, you just make the functionality public but 
undocumented. And while that may not be ideal, I really don't think that it 
will happen enough to be worth the complication to the language required to 
avoid it.

And consider the fact that even with your suggested changes, there are going 
to be ways that you can't refactor your code and still keep it using the same 
API and/or the same access level. We can pretty much always find more ways to 
refactor code that won't work with the access specifiers unless you introduce 
something like friend which allows you to explicitly specify who can access 
who rather than using general groups like public and private. And you have to 
draw the line somewhere.

I think that making it so that the package access specifier lets nested 
packages access it in addition to the exact package is a good balance between 
simplicity and power.

However, if you want to try and convince Walter, feel free. But from what he's 
said in the past, I suspect that he leans more towards getting rid of package 
entirely than thinking that it's worth making it more complicated in the 
manner that you're looking for.

- Jonathan M Davis