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

On 6/7/13, nazriel <spam@dzfl.pl> wrote:
> 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.

This could come as a benefit. For example, a user might not know exactly which modules a package module is composed of, so he'll instinctively try to type "std.datetime.time" and it will work.

On Friday, June 07, 2013 10:55:36 nazriel wrote:
> 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.

Actually, Daniel Murphy, Martin Nowak, and I discussed it with Walter and Andrei at dconf the night of Adam's talk, so it wasn't on the newsgroup. There's nothing secret about it though. It's just that it was discussed in person, so there is no record. I believe that some further discussion has occured in the newsgroup in the two pull requests for it as well as the DIP announcement, but we went into a fair bit of detail in the discussion at dconf of what exactly the pros and cons would be as well as the side effects.

What's really nice about DIP 37 is that it takes advantage of a number of existing features rather than requiring much new. It's essentially just taking what currently works with a module like all.d (publicly importing the everything in the package in the one module) and making it work in a manner that we can avoid code breakage. And naming the file package.d is a particular stroke of genius (provided by someone in the original discussion on Martion Nowak's DIP on the issue IIRC), because then the file can't even conflict with any existing code. So, while the implementation does have some definite nuances to it (like making sure that using the explict path to something like std.datetime.DosFileTime still works), it's ultimately fairly simple and straightforward. And given the need to break up modules in place, we decided that it was worth implementing.

- Jonathan M Davis

On Thursday, 6 June 2013 at 06:09:41 UTC, Max Samukha wrote:
>
> 'package' should be fixed so that 'package' declarations are accessible within nested packages.

I don't think the 'package' access specifier should give privileges to *all* nested packages. Rather, I think we just need to invent a new word, and then specifying what 'package' access specifier does becomes easy. My suggestion for this new word is "module-pack"...

Module-pack:
"A folder which has a file called package.d inside it. Can be imported as if it was a module. etc."

...then, the definition of 'package' access modifier would be:

"The label package can be specified at class level, outside all classes (module-level), or inside a struct. In all contexts, package introduces protection that allows access to the symbol to all modules and module-packs which are either within the same directory as the current module or within the same directory as the module-pack which holds the current module within. Non-module-pack subdirectories and the parent directory of the current module’s directory have no special privileges."

Basically we'd pretend that module-packs are like modules.

On Wednesday, June 19, 2013 06:49:49 TommiT wrote:
> On Thursday, 6 June 2013 at 06:09:41 UTC, Max Samukha wrote:
> > 'package' should be fixed so that 'package' declarations are accessible within nested packages.
> 
> I don't think the 'package' access specifier should give privileges to *all* nested packages. Rather, I think we just need to invent a new word, and then specifying what 'package' access specifier does becomes easy. My suggestion for this new word is "module-pack"...
> 
> Module-pack:
> "A folder which has a file called package.d inside it. Can be
> imported as if it was a module. etc."
> 
> ...then, the definition of 'package' access modifier would be:
> 
> "The label package can be specified at class level, outside all classes (module-level), or inside a struct. In all contexts, package introduces protection that allows access to the symbol to all modules and module-packs which are either within the same directory as the current module or within the same directory as the module-pack which holds the current module within. Non-module-pack subdirectories and the parent directory of the current module’s directory have no special privileges."
> 
> Basically we'd pretend that module-packs are like modules.

I _really_ don't like the idea of having the presence of package.d affect the package modifier, and I don't think that anything which controls how many levels deep the package modifier gives the package access to is worth the extra complication. If it's worth letting nested packages have access to their parent packages package-level stuff, then let's just do that for everything. Trying to make it configurable really doesn't buy us much and adds yet more complication to an already complicated language.

- Jonathan M Davis

On Wednesday, 19 June 2013 at 05:35:17 UTC, Jonathan M Davis wrote:
> I _really_ don't like the idea of having the presence of package.d affect the package modifier, and I don't think
> that anything which controls how many levels deep the
> package modifier gives the package access to is worth the extra complication.

I don't like the extra complication either, but I think it's the lesser of two evils. Worse is a situation where you would want to break multiple modules, but you can't do it easily because of the way you've structured your code up to that point.

On Wednesday, 19 June 2013 at 05:35:17 UTC, Jonathan M Davis wrote:
> If it's worth letting nested packages have access to their parent packages package-level stuff, then
> let's just do that for everything.

But this is not enough. Let's say you have modules A.d and B.d under the same package. Now, if A.d uses something that is marked 'package' inside B.d, you can't break both A.d and B.d into these new module-package thingies without re-structuring your code.

On Wednesday, 19 June 2013 at 06:25:02 UTC, TommiT wrote:
> Now, if A.d uses something that is marked 'package' inside B.d, you can't break both A.d and B.d into these new module-package thingies without re-structuring your code.

And it may not be even possible to re-structure the code, like when the thing marked 'package' is a member function for example.

On Wednesday, June 19, 2013 08:25:00 TommiT wrote:
> > If it's worth letting nested packages have access to their
> > parent packages package-level stuff, then
> > let's just do that for everything.
> 
> But this is not enough. Let's say you have modules A.d and B.d under the same package. Now, if A.d uses something that is marked 'package' inside B.d, you can't break both A.d and B.d into these new module-package thingies without re-structuring your code.

Then just put whatever is supposed to be shared between them in the package that they were both in originally. package stuff is not part of the public API, so when you're refactoring package code, you're refactoring code that you own entirely, so it shouldn't be an issue if you have to rearrange it a bit, especially since it's all localized to a single package by definition. It's only when something is part of a public API that refactoring becomes a problem.

- Jonathan M Davis

On Wednesday, 19 June 2013 at 06:25:02 UTC, TommiT wrote:
>
> I don't like the extra complication either, ...

I should have said, I don't like the added complexity. But I think this is one of those things that becomes totally obvious once you use it for a while and get used to thinking about these packaged-module thingies as just simply modules.

On Wednesday, 19 June 2013 at 06:47:05 UTC, Jonathan M Davis wrote:
> Then just put whatever is supposed to be shared between them in the package
> that they were both in originally. package stuff is not part of the public API,
> so when you're refactoring package code, you're refactoring code that you own
> entirely, so it shouldn't be an issue if you have to rearrange it a bit,
> especially since it's all localized to a single package by definition. It's
> only when something is part of a public API that refactoring becomes a
> problem.
>
> - Jonathan M Davis

I can't put a member function into a different file if it's supposed to have access to private data of its enclosing class/struct.