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