On Thursday, June 06, 2013 08:31:57 Marco Leise wrote:
> If package is ambiguous, maybe it needs to be split in two or take a parameter package(std.algorithm) or something like that to serve both use cases.

While that might be nice, I'm inclined to think that it would be better to avoid the extra complication and just pick the behavior that seems the most useful. In neither case is the loss all that large, particularly since package is likely to be used fairly rarely. It's quite useful to be sure, but it has a narrow enough set of typical use cases that complicating it probably isn't worth it.

- Jonathan M Davis

On Thursday, 6 June 2013 at 06:26:17 UTC, Jonathan M Davis wrote:
> On Thursday, June 06, 2013 08:09:38 Max Samukha wrote:
>> On Thursday, 6 June 2013 at 02:36:12 UTC, Jonathan M Davis wrote:
>> > But I believe that package level access only works on the same
>> > level, so you
>> > couldn't have separate modules for compressing and
>> > decompressing as was being
>> > suggested.
>> 
>> 'package' should be fixed so that 'package' declarations are
>> accessible within nested packages.
>
> Well, it _is_ debatable as to whether that's desirable or not. With the
> current behavior, you can have a package which shares stuff within itself but
> not with its sub-packages, but there's no way to share with the sub-packages
> without making the symbols public; whereas if sub-packages have access to
> their parent packages' package functions, then packages _can_ share with their
> sub-packages, but they can't restrict anything to just the package. Both ways
> have their pros and cons. I don't know which is ultimately better.

There is not much to debate. Get your hands dirty with a real project having more than two levels of packages and you'll see that the first is ultimately better.

While limiting 'package' to one level may be sometimes desirable, forcing package-private members to be world-public is highly undesirable. As a package author I can tolerate loose access policies within a package tree that *I* control but I definitely don't want to expose to the user of my package what he shouldn't have access to.

On 6/6/13, Max Samukha <maxsamukha@gmail.com> wrote:
> There is not much to debate. Get your hands dirty with a real project having more than two levels of packages and you'll see that the first is ultimately better.

I've argued the same thing before. And as a cream on top I'd like allowing package on virtual methods. That way I can have internal virtual methods which can be extended in other modules or modules in subpackages (if the two features are supported). This allows me to specialize behavior in subclasses, but at the same time disallows the user from calling such methods (a final protected override comes close, except it will still be callable in user-code).

Currently the way I work around this is to prepend an underscore to a public virtual and not document the method. It's very much a convention thing.

I could instead use some kind of template mixin.. but those are so full of bugs that I eagerly avoid them.

On Wednesday, 5 June 2013 at 22:31:21 UTC, Andrei Alexandrescu wrote:
> https://github.com/D-Programming-Language/dmd/pull/2139
>
> Andrei

I had a spin[1] with it long before Adam Wilson made it so popular topic. Feature was frequently mentioned on IRC as desired. Unfortunately I faced few holes in both Martin's and Andrei's DIPs and gave up on implementing it.

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

---

My point is, are directions Jonathan wants to go are right?
I think std.datetime.Foo shouldn't be available.

I remember also having some issues with ambiguous symbols. I had more corner cases in IRC Logs, but can't find it now.

Also I see we are going with Andrei's DIP route.
It is worth noting that Martin's one may have some additional functionality.

Like glueing modules. Ie.

---

module std.net;

public import std.net.http;
public import std.net.uri;

shared(Uri) uri = new shared(Uri);

---

In Martin's proposal uri symbol is reachable via
std.net.__init__.uri in case of ambiguous. In Andrei's it is unreachable due to package being keyword.

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

[1] https://github.com/nazriel/dmd/tree/dip16++

On Thursday, June 06, 2013 13:47:29 Andrej Mitrovic wrote:
> I've argued the same thing before. And as a cream on top I'd like allowing package on virtual methods. That way I can have internal virtual methods which can be extended in other modules or modules in subpackages (if the two features are supported). This allows me to specialize behavior in subclasses, but at the same time disallows the user from calling such methods (a final protected override comes close, except it will still be callable in user-code).

Well, since Walter seems to have been convinced in the "Slow performance compared to C++, ideas?" thread to make it so that non-virtual is the default, the presumably it could be changed so that package could be virtual when it's marked as virtual.

- Jonathan M Davis

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

On 6/6/2013 11:09 AM, Jonathan M Davis wrote:
> 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.

The only reason I'm for it is because we need to break up std.algorithm (for the canonical example) without breaking existing code.

I'm sure the problem with:

simple module => kitchen sink monstrosity => break up module

is a recurring issue that most everyone has sooner or later. We need to support it.

On Thursday, June 06, 2013 11:16:03 Walter Bright wrote:
> On 6/6/2013 11:09 AM, Jonathan M Davis wrote:
> > 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.
> 
> The only reason I'm for it is because we need to break up std.algorithm (for the canonical example) without breaking existing code.
> 
> I'm sure the problem with:
> 
> simple module => kitchen sink monstrosity => break up module
> 
> is a recurring issue that most everyone has sooner or later. We need to support it.-

Yes. If it weren't for the need to break up modules in-place without breaking code, then I'd argue for simply using the foo/all.d idiom where all.d publicly imports all of the modules in foo. Then you just import foo, and you get everything. IMHO, that solves the need for importing packages well enough to avoid needing a language change for it. People have been using it for that already. But it _doesn't_ allow you to break up modules in place without breaking code, which is why I think that this DIP is worth implementing.

So, I think that we're in pretty strong agreement about it at this point.

As the C# article on virtuality that we've been discussing underlines, features which promote being able to evolve code can be very valuable, and I think that we have some good additions in that camp over languages like C++ or Java (alias this and deprecated in particular come to mind) - maybe not as many as would be nice, but we do have some solid features for code evolution. And I think that this will be a good addition to that.

- Jonathan M Davis

Can we use some other word for counterargument than destroy please. :(

(resume discussion)

On Thu, 06 Jun 2013 22:59:41 +0200, Sad panda <sunspyre@gmail.com> wrote:

> Can we use some other word for counterargument than destroy please. :(
>
> (resume discussion)

But we like destroy.

-- 
Simen