Time to destroy Walter: breaking modules into packages

Jonathan M Davis jmdavisProg at gmx.com
Thu Jun 6 12:27:02 PDT 2013


On Thursday, June 06, 2013 11:16:03 Walter Bright wrote:
> On 6/6/2013 11:09 AM, Jonathan M Davis wrote:
> > We've already discussed this at length. It's possible that we missed
> > something, but this proposal is not something that we just jumped into
> > without thinking it through first. In fact, it actually took quite a bit
> > to talk Walter into the necessity of it in the first place.
> 
> The only reason I'm for it is because we need to break up std.algorithm (for
> the canonical example) without breaking existing code.
> 
> I'm sure the problem with:
> 
> simple module => kitchen sink monstrosity => break up module
> 
> is a recurring issue that most everyone has sooner or later. We need to
> support it.-

Yes. If it weren't for the need to break up modules in-place without breaking 
code, then I'd argue for simply using the foo/all.d idiom where all.d publicly 
imports all of the modules in foo. Then you just import foo, and you get 
everything. IMHO, that solves the need for importing packages well enough to 
avoid needing a language change for it. People have been using it for that 
already. But it _doesn't_ allow you to break up modules in place without 
breaking code, which is why I think that this DIP is worth implementing.

So, I think that we're in pretty strong agreement about it at this point.

As the C# article on virtuality that we've been discussing underlines, 
features which promote being able to evolve code can be very valuable, and I 
think that we have some good additions in that camp over languages like C++ or 
Java (alias this and deprecated in particular come to mind) - maybe not as 
many as would be nice, but we do have some solid features for code evolution. 
And I think that this will be a good addition to that.

- Jonathan M Davis


More information about the Digitalmars-d mailing list