Time to destroy Walter: breaking modules into packages
nazriel
spam at dzfl.pl
Fri Jun 7 01:55:36 PDT 2013
On Thursday, 6 June 2013 at 18:10:11 UTC, Jonathan M Davis wrote:
>
> 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.
>
Ok, after carefully rereading thread now I understand your point.
Preventing breakage when std.datetime is splited into sub
packages - ok.
But still it looks weird to me that allowing access to
std.datetime.time.Clock via std.datetime.Clock, even though Clock
is defined in std.datetime.time and std.datetime.package is only
publicly importing it, is ok. I guess whatever suits you :))
>> 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;
>
Ach pardon, I am lost in all those DIPs. I recalled that Andrei's
proposed package.d file, those I referred to your DIP37 (which
seems to be summary of Andrei's DIP?) as Andrei's
>> 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.
>
Sorry, it is just the impression that this feature was requested
very long time ago, Martin's and Andrei's DIPs were staging and
recently talk by Adam Wilson made it interesting to the D "crew".
If it was carefully discussed and I somehow missed those
discussion or I am not allowed to see them, then I am sorry and
please ignore this and my previous post in this topic.
> - Jonathan M Davis
Best regards,
Damian Ziemba
More information about the Digitalmars-d
mailing list