Time to destroy Walter: breaking modules into packages

Jonathan M Davis jmdavisProg at gmx.com
Thu Jun 20 00:59:36 PDT 2013


On Thursday, June 20, 2013 08:45:21 TommiT wrote:
> On Thursday, 20 June 2013 at 05:24:12 UTC, TommiT wrote:
> > This is how I see the logic of this new feature you're adding:
> > 
> > When you have a folder named "mod" which contains a file named
> > package.d, the mod folder becomes conceptually a file with same
> > name and the extension "d". I.e. the folder conceptually
> > becomes a module, which you can then import to other modules.
> > All the code contained within all the files contained within
> > the mod folder becomes conceptually the content of this
> > imaginary mod.d file. Therefore it is only logical that all the
> > code within this imaginary mod.d file would have access to
> > 'package'-labeled symbols that are in files which are located
> > under the same folder under which this imaginary mod.d file is.
> 
> ...and following that thread, I would also argue, that
> 'private'-labeled symbols in files that are inside this mod
> folder should be accessible to all the other files that are
> inside this mod folder, because conceptually all those files are
> part of the same (imaginary) module (mod.d).

The _only_ reason that we added package.d was to allow us to split up modules 
in place without breaking existing code. And it works as well as it does, 
because the _only_ new feature that it provides is making it so that when you 
import a package, you import package.d. All other aspects about it were 
already part of the language, and we weren't looking to add any new 
functionality whatsoever beyond being able to break up modules like 
std.algorithm or std.datetime. Trying to treat a package as if it were a 
module because it has a package.d file is contorting things considerably. That 
was never the intention of package.d at all. It's to help us evolve code 
without breaking public APIs. package is not part of the public API. private 
is not part of the public API. As such, they have _nothing_ to do with the 
purpose of package.d. And it was never intended that packages be treated as 
modules due to the presence of package.d save for the purpose of avoiding code 
breakage. IMHO, you are trying to take this _way_ too far.

- Jonathan M Davis


More information about the Digitalmars-d mailing list