Time to destroy Walter: breaking modules into packages

Jonathan M Davis jmdavisProg at gmx.com
Wed Jun 19 13:05:41 PDT 2013


On Wednesday, June 19, 2013 13:13:54 TommiT wrote:
> On Wednesday, 19 June 2013 at 07:12:30 UTC, Jonathan M Davis
> 
> wrote:
> > [..] But even if you can't, I don't think that it's worth it to
> > complicate the package attribute any further. [..]
> 
> I'd like to quote the TDPL foreword by Walter:
> "To the best of my knowledge, D offers an unprecedentedly adroit
> integration of several powerful programming paradigms:
> imperative, object-oriented, functional, and meta.
> At first blush, it would appear that such a language could not be
> simple. And indeed, D is not a simple language. But I’d argue
> that is the wrong way to view a language. A more useful view is,
> what do programming solutions in that language look like? Are D
> programs complicated and obtuse, or simple and elegant?"
> -Walter Bright
> 
> Thus, we shouldn't strive so much to make the language simple (by
> having the simplest possible definition for the 'package'
> keyword), but rather, we should try to make programs, which use
> modules broken into packages, look simple, elegant and easy to
> understand.

Sure, but there's a limit to how much complexity is reasonable, and every 
feature has to pull its own weight. And while I agree that there are cases 
where refactoring packages may cause complications with the package modifier 
specfically giving nested packages access to their parent packages' package 
stuff but not do anything like what you're suggesting, I don't agree that it's 
a big enough deal to merit complicating the package access level any further. 
If it's a problem, then maybe the code just plain needs to be redesigned 
rather than simply shuffled around. If we were really looking for full power 
with rearranging stuff like that, we'd have friend functions and classes, and D 
specifically elected _not_ to go for that level of complication. And overall, 
it's worked great for us thus far.

- Jonathan M Davis


More information about the Digitalmars-d mailing list