March 31, 2012
Le 30/03/2012 21:33, Andrei Alexandrescu a écrit :
> On 3/30/12 1:39 PM, Jonathan M Davis wrote:
>> However, I'm very nervous about the second part. e.g. std.sort instead of
>> std.algorithm.sort seems like a bad idea to me. It increases the odds
>> of name
>> conflicts for little benefit.
>
> Example?
>
>> Not to mention, it'll make it a lot more confusing
>> to find what modules stuff is actually in if people start doing stuff
>> like
>>
>> std.sort(arr);
>>
>> In the case of sort, you may know where it's from - particularly since
>> it's so
>> common - but the less well-known the function is, the less likely that
>> is at
>> all obvious where it comes from, and if you're dealing with 3rd party
>> software, then it wouldn't be at all obvious. For instance, how would
>> you know
>> that party.foo is really party.bar.foo? You wouldn't.
>
> Why should you?
>
>> Being so lax about
>> importing could really harm code readibility (and maintainibility,
>> since it
>> increases the odds of name clashes). So, I'm inclined to say that that
>> is a
>> _bad_ idea.
>
> Maybe if you produce a solid example, I'd be convinced.
>
>
> Andrei

You are reversing the logic. It have to be shown that it is not a problem to do the change. The other way around is flawed logic.
March 31, 2012
Le 30/03/2012 23:35, Jonathan M Davis a écrit :
> On Friday, March 30, 2012 14:33:58 Andrei Alexandrescu wrote:
>> On 3/30/12 1:39 PM, Jonathan M Davis wrote:
>>> However, I'm very nervous about the second part. e.g. std.sort instead of
>>> std.algorithm.sort seems like a bad idea to me. It increases the odds of
>>> name conflicts for little benefit.
>>
>> Example?
>
> std.sort works because there's only one sort. If there are two, you get a
> conflict (e.g. if you had std.path.sort which sorted paths in some path-specific
> manner). If std.path.sort existed now, then std.sort wouldn't work, and you'd
> be forced to specify std.algorithm.sort or std.path.sort, and that's fine. It
> would be similar to having to specify std.algorithm.indexOf when you've
> imported both std.string and std.algorithm. But the problem is when
> std.path.sort is added _later_.
>

I mentionned that as being a ptotential issue, so this is a +1 .

> But personally, I like the idea of making it so that publicly imported symbols
> can be accessed as if they were in the module that publicly imported them
> (with package.d being treated as if it had the same name as the package that
> it's in). That's essentially how it already works except when specifying the
> full import path for a symbol. And that way, you can specify in
> std.algorithm.package.d exactly what you want to be imported when
> std.algorithm is imported (including using : to restrict it to specific symbols
> in a module), and only those symbols will be treated as if they were part of
> std.algorithm - both for importing purposes and when specifying the import
> path when using a symbol. The library maintainer then has control over which
> symbols get used with which import paths.
>
> - Jonathan M Davis

I did propose that in another thread, so this is a +1 too.
March 31, 2012
On 03/31/2012 03:49 PM, Martin Nowak wrote:
> On Sat, 31 Mar 2012 13:06:36 +0200, Timon Gehr <timon.gehr@gmx.ch> wrote:
>
>> On 03/30/2012 11:35 PM, Jonathan M Davis wrote:
>>> But personally, I like the idea of making it so that publicly
>>> imported symbols
>>> can be accessed as if they were in the module that publicly imported
>>> them
>>
>> +1. That is even better than treating the package module specially.
>
> That already works, doesn't it?

It already works indeed. My bad.
March 31, 2012
> However, I'm very nervous about the second part. e.g. std.sort instead of
> std.algorithm.sort seems like a bad idea to me. It increases the odds of name
> conflicts for little benefit. Not to mention, it'll make it a lot more confusing
> to find what modules stuff is actually in if people start doing stuff like
>
> std.sort(arr);

You can turn that argument around, std.sort(arr) instead of sort(arr)
provides some extra context for disambiguation.
You'd be able to do that for public imports in the package.d module anyhow,
so it makes sense to support it for implicit packages as well.
March 31, 2012
Le 30/03/2012 16:46, Andrei Alexandrescu a écrit :
> Starting a new thread from one in announce:
>
> http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16
>
> Please comment, after which Walter will approve. Walter's approval means
> that he would approve a pull request implementing DIP16 (subject to
> regular correctness checks).
>
>
> Destroy!
>
> Andrei

OK, here is an alternative proposal, based on what has been said here, and in other thread. I think it is a better alternative because it is almost already working.

1/ you can defined both a.d (d source code) and a (folder) in the same folder.
2/ import a; will always look for a.d . a folder. a existing isn't an error.
3/ import a.b will look for b.d in a folder. If a.d exists, it isn't an error.
4/ The package a include what in a.d and everything defined in d files in the folder a and its subfolders.
5/ What is publicly imported get automatically aliased in the importing module. See example below if it is not clear :

a.d :

public import a.b;

b.d :

void foo() {}

automatic aliasing in a.d would look like :

public import a.b;

// Automaticaly added aliases :
alias b.foo foo;

And usage from third party code :

import a;

void main() {
    foo();       // OK
    a.foo();     // OK
    a.b.foo();   // OK
}

And with static import :

static import a;

void main() {
    foo();       // Error
    a.foo();     // OK
    a.b.foo();   // OK
}
March 31, 2012
On Saturday, March 31, 2012 17:30:36 Timon Gehr wrote:
> On 03/31/2012 03:49 PM, Martin Nowak wrote:
> > On Sat, 31 Mar 2012 13:06:36 +0200, Timon Gehr <timon.gehr@gmx.ch> wrote:
> >> On 03/30/2012 11:35 PM, Jonathan M Davis wrote:
> >>> But personally, I like the idea of making it so that publicly
> >>> imported symbols
> >>> can be accessed as if they were in the module that publicly imported
> >>> them
> >> 
> >> +1. That is even better than treating the package module specially.
> > 
> > That already works, doesn't it?
> 
> It already works indeed. My bad.

Does it? I thought that std.range.replace wouldn't work (even though std.range publicly imports std.array), because replace isn't part of std.range. You don't need to import std.array if you import std.range, because std.range does, but you can't specificy it's path as if it were in std.range. I'll have to check...

Okay. You're right. std.range.replace _does_ work. So then the only issue is making it so that public imports in std.datetime.package are treated as if they were in std.datetime. That seems like the cleanest solution to me. It goes along quite nicely with making it so that anything in std.datetime.package is imported when importing std.datetime.

- Jonathan M Davis
April 02, 2012
On Fri, 30 Mar 2012 17:45:36 -0400, Michel Fortin
<michel.fortin@michelf.com> wrote:

> On 2012-03-30 14:46:19 +0000, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:
>
>> Destroy!
>
> Since you're asking…
>
> One thing the current system avoids is unresolvable symbols. If two symbol name clashes, you just qualify them fully and it'll always be unambiguous. For instance:
>
> 	.std.algorithm.sort(…)
>
> Now, if std.algorithm becomes both a module and a package, you could have both a sort function and a sort submodule with no way to distinguish between the two, even when fully qualified. I think this is why D does not allow modules to have the same name as packages.
>
> I understand that you try to work around this problem by inventing a .std.algorithm.package scope. Then you make it's content imported automatically inside the .std.algorithm scope for backward compatibility (and convenience). The problem is that if .std.algorithm.package contains a sort function and there is also a module called std.algorithm.sort, the fully-qualified name of that 'sort' module will become ambiguous. Moreover, whether the fully-qualified name .std.algorithm.sort is ambiguous or not depends on what modules were imported, which is not a very desirable behaviour.

So this becomes an error.  I don't see this as a major problem.  Just
don't name a module sort inside std/algorithm.

This is no different than ambiguous templates, which are allowed until you
want to instantiate one.

-Steve
April 02, 2012
On Sat, 31 Mar 2012 00:23:32 -0400, Chris NS <ibisbasenji@gmail.com> wrote:

> I'm pretty impressed with the idea, and look forward to its implementation, but I do have one question.  How does this affect (if at all) the implicit "friend" relationship of declarations?  Since package "foo.bar" is treated as a single module, do the classes in "foo/bar/alpha.d" and "foo/bar/beta.d" have access to each other's private members?
>
> I'm not sure whether I favor them losing or keeping their "friend" status.

They would lose their friend status.  Classes that you need to be "friends" would have to go into the same submodule, which makes perfect sense to me.

-Steve
April 03, 2012
On 2012-04-02 13:04:31 +0000, "Steven Schveighoffer" <schveiguy@yahoo.com> said:

> On Fri, 30 Mar 2012 17:45:36 -0400, Michel Fortin
> 
>> The problem is that if .std.algorithm.package
>> contains a sort function and there is also a module called
>> std.algorithm.sort, the fully-qualified name of that 'sort' module wil l
>> become ambiguous. Moreover, whether the fully-qualified name
>> .std.algorithm.sort is ambiguous or not depends on what modules were
>> imported, which is not a very desirable behaviour.
> 
> So this becomes an error.  I don't see this as a major problem.  Just
> don't name a module sort inside std/algorithm.
> 
> This is no different than ambiguous templates, which are allowed until y ou
> want to instantiate one.

If you have ambiguous templates in the same module, it'll always be ambiguous irrespective of what you import (and you can blame the module's designer for it). If you have ambiguous templates residing in different modules the symbol will be unambiguous until you've imported the second module (same as overloaded functions). At that point you can disambiguate using the fully-qualified name of the template (or function).

Whereas if the fully-qualified name of a module becomes ambiguous because of a symbol in another module, there is no way to disambiguate. All you can do is avoid importing the two conflicting modules together, just like when you encounter two headers trying to define the same symbol in C/C++.

With the way D modules were designed, this cannot happen because you can't have a module with the same name as a package. I always thought this was done on purpose, but I might be wrong. Whatever we do, I think it'd be a nice property to preserve that fully-qualified names should always work.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

April 03, 2012
On Fri, 30 Mar 2012 16:46:19 +0200, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Starting a new thread from one in announce:
>
> http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16
>
> Please comment, after which Walter will approve. Walter's approval means that he would approve a pull request implementing DIP16 (subject to regular correctness checks).
>
>
> Destroy!
>
> Andrei

What about supporting package initalization?
I basically proposed that if a submodule of a package
was imported, a static import of the package is implicitly
added.
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP15