Time to destroy Walter: breaking modules into packages

Jonathan M Davis jmdavisProg at gmx.com
Thu Jun 6 11:09:55 PDT 2013


On Thursday, June 06, 2013 16:53:37 nazriel wrote:
> Few issues I remember were:
> 
> module std.datetime.core;
> class Foo {}
> 
> module std.datetime.calendar;
> class Foo {}
> 
> module std.datetime;
> 
> public import std.datetime.core;
> public import std.datetime.calendar;
> 
> module usage;
> 
> import std.datetime;
> 
> Foo x; // is it std.datetime.core or std.datetime.calender?
> 
> // ok workaround..
> std.datetime.Foo x; // same issue as above
> 
> std.datetime.core.Foo x; // works atleast

If you have that problem, then you don't publicly import the entire module. 
It's up to the package designer to decide which portions of the package get 
publicly imported. But since std.datetime.Foo would be ambiguous, I don't 
think that it really matters anyway. In that case, you're simply forced to 
refer to it by its actual module rather than by the package. The only time 
that something like this is likely to be a concern is when you add a 
conflicting function to another module in the package, because then 
std.datime.Foo was working and then ceased to work. That's arguably cause for 
being careful about what you choose to publicly import in package.d, but I 
don't think that it invalidates the feature design at all.

> Also I see we are going with Andrei's DIP route.

How so? What Walter has done is almost identical to DIP 37. I believe that the 
only difference is that std.datetime.package would have module std.datetime; at 
the top, whereas DIP 37 currently says that it would have module 
std.datetime.package;

> I am glad Walter is tackling it, because it is really useful
> feature, but please take a chill pill and rethink all corner
> cases.

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.

- Jonathan M Davis


More information about the Digitalmars-d mailing list