Time to destroy Walter: breaking modules into packages

TommiT tommitissari at hotmail.com
Thu Jun 20 02:15:51 PDT 2013


On Thursday, 20 June 2013 at 07:59:57 UTC, Jonathan M Davis wrote:
>
> 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

Ok. Then this feature is not really about being able to easily 
break an existing module into a package, but rather about 
providing a different way to organize your code from the get-go. 
You _can_ break existing modules into packages, but you may need 
to go through some hoops to do so, and that's fine, because 
that's not the primary purpose of this feature anyway.

I'd say let's keep the package access specifier as it is now.


More information about the Digitalmars-d mailing list