Jump to page: 1 211  
Page
Thread overview
DIP16: Transparently substitute module with package
Mar 30, 2012
deadalnix
Mar 30, 2012
Timon Gehr
Mar 30, 2012
Timon Gehr
Mar 30, 2012
Nick Sabalausky
Mar 30, 2012
Robert Clipsham
Mar 30, 2012
Nick Sabalausky
Mar 30, 2012
Andrej Mitrovic
Mar 30, 2012
Nick Sabalausky
Mar 30, 2012
Brad Anderson
Mar 30, 2012
F i L
Mar 30, 2012
Andrej Mitrovic
Mar 30, 2012
Jonathan M Davis
Mar 30, 2012
Rene Zwanenburg
Mar 30, 2012
Jonathan M Davis
Mar 31, 2012
Timon Gehr
Mar 31, 2012
Martin Nowak
Mar 31, 2012
Timon Gehr
Mar 31, 2012
Jonathan M Davis
Mar 31, 2012
deadalnix
Mar 30, 2012
H. S. Teoh
Mar 31, 2012
deadalnix
Mar 31, 2012
Martin Nowak
Mar 30, 2012
Jonathan M Davis
Mar 30, 2012
Jonathan M Davis
Mar 30, 2012
Nick Sabalausky
Mar 30, 2012
Michel Fortin
Apr 03, 2012
Michel Fortin
Apr 04, 2012
Michel Fortin
Apr 04, 2012
Timon Gehr
Apr 05, 2012
Michel Fortin
Apr 05, 2012
Michel Fortin
Apr 05, 2012
deadalnix
Apr 05, 2012
Timon Gehr
Apr 05, 2012
Jonathan M Davis
Apr 05, 2012
Jonathan M Davis
Apr 05, 2012
Jonathan M Davis
Apr 05, 2012
Michel Fortin
Apr 06, 2012
deadalnix
Apr 06, 2012
deadalnix
Apr 06, 2012
David Gileadi
Apr 06, 2012
deadalnix
Apr 06, 2012
deadalnix
Apr 06, 2012
Michel Fortin
Apr 07, 2012
Jonathan M Davis
Apr 07, 2012
Jacob Carlborg
Apr 07, 2012
Jonathan M Davis
Apr 08, 2012
Kapps
Apr 09, 2012
Jonathan M Davis
Apr 05, 2012
deadalnix
Apr 05, 2012
Michel Fortin
Apr 05, 2012
deadalnix
Apr 05, 2012
Michel Fortin
Apr 05, 2012
Jonathan M Davis
Apr 05, 2012
Jonathan M Davis
Apr 05, 2012
Jonathan M Davis
Apr 07, 2012
Jonathan M Davis
Apr 05, 2012
deadalnix
Apr 05, 2012
deadalnix
Apr 04, 2012
Jacob Carlborg
Mar 30, 2012
Ary Manzana
Mar 31, 2012
Chris NS
Mar 31, 2012
Nick Sabalausky
Mar 31, 2012
Chris NS
Mar 31, 2012
Derek
Mar 31, 2012
foobar
Mar 31, 2012
deadalnix
Apr 03, 2012
Martin Nowak
Apr 04, 2012
deadalnix
Apr 05, 2012
Martin Nowak
Apr 05, 2012
deadalnix
Apr 06, 2012
Ary Manzana
March 30, 2012
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
March 30, 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

I was waiting for it :D

First, as all.d is already a convention in many D projects, why choose package.d ? I understand this is a keyword, but this will also be painfull for many developer.

Second, what the rule of a .d file and a folder existing, but in different path (think -I switch of the compiler).

In the first place, is the module declaration really usefull ?

About the lookup rule, I understand that if I import a.b and use the function a.b.c.foo , then i must be able to refers to it as a.b.foo, but why a.foo ? It seems to me like going too far in the modification for no benefit (it can only increase the number of collision, and has no benefit I can think of).
March 30, 2012
On 03/30/2012 04:46 PM, Andrei Alexandrescu 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


Those are two proposals.

I think the first one should be implemented.


I don't really like the second one.

1. It is an over-general solution, because it does not solve a general problem.

2. Library writers lose control. All symbol names in the package are reserved when the package is deployed. It will be a breaking change to introduce a sub-package that happens to have the same name as some symbol defined in any module in the same package hierarchy.

3. symbol lookup is already hard enough to get right, because compile time reflection and conditional code generation can introduce ambiguities and contradictions. DMD does not get it right. It is likely that this change would make fixing this in a general but not-too-conservative way considerably harder.


Maybe it would be better to just interpret foo.bar.baz as foo.bar.package.baz if foo.bar is a package that has been imported via the foo.bar.package rewrite? Of course, issue 2 probably would remain.
March 30, 2012
On second thought, issue 2 is probably not that much of a problem.
March 30, 2012
On 30/03/2012 15:46, Andrei Alexandrescu 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

The proposal doesn't say what happens when package.d is not found but foo/bar/ exists.

Given that a lot of people will just use public import foo.bar.*; in that file, would it make sense for package.d missing to imply import foo.bar.*? That would save typing out every single file in there. Of course it would also be annoying if you wanted to import everything except one file, as you'd then have to type out every single import anyway.

The other option is to error, which is probably a more sane option.

-- 
Robert
http://octarineparrot.com/
March 30, 2012
On Fri, 30 Mar 2012 10:46:19 -0400, 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).

I think package.d should be allowed to specify module.  Otherwise, something like /usr/include/d/std/datetime/package.d, what is the assumed package?  If module is not useful here, it is not useful anywhere.

I think the omission should be strictly anything after the package directory.  For example, if you have std/algorithm/package.d and std/algorithm/sorting.d, where package.d imports sorting.d, you can refer to std.algorithm.sorting.sort by omitting sorting, but not by omitting algorithm or std.

Other than that, this is a good change.

-Steve
March 30, 2012
On 3/30/12, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> Destroy!

"That means a program that imports std.algorithm may use "std.sort" for the symbol "std.algorithm.sort"."

That's quite interesting. Would that also mean that you could do:
import std.algorithm;  // has indexOf
import std.string;  // has indexOf
void main() {
    string.indexOf("foo", "foo"); -> std.string.indexOf
}

That would ease usage of Phobos a little bit. OTOH 'string' already is a keyword and things might get hairy..

Still this is one of the few proposals I like. My only caveat is the
comment: "except the file is not allowed to use the "module"
declaration.". Wouldn't it be better if we explicitly declared a
module as a package instead? In foo\bar\package.d:
package foo.bar;

Since the "module" declaration must be on the first line (or second line after shebang), you could special-case DMD to allow the package keyword to be used here. I know D likes to abuse a keyword for multiple things (hello Mr. Static!), but I think we could live with it.
March 30, 2012
On Fri, Mar 30, 2012 at 12:06 PM, Andrej Mitrovic < andrej.mitrovich@gmail.com> wrote:

> On 3/30/12, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> > Destroy!
>
> "That means a program that imports std.algorithm may use "std.sort" for the symbol "std.algorithm.sort"."
>
> That's quite interesting. Would that also mean that you could do:
> import std.algorithm;  // has indexOf
> import std.string;  // has indexOf
> void main() {
>    string.indexOf("foo", "foo"); -> std.string.indexOf
> }
>
>
I was actually kind of surprised when I found out this doesn't work.  It seems so natural to resolve ambiguity using as little context as necessary.


> That would ease usage of Phobos a little bit. OTOH 'string' already is a keyword and things might get hairy..
>
> Still this is one of the few proposals I like. My only caveat is the
> comment: "except the file is not allowed to use the "module"
> declaration.". Wouldn't it be better if we explicitly declared a
> module as a package instead? In foo\bar\package.d:
> package foo.bar;
>
> Since the "module" declaration must be on the first line (or second line after shebang), you could special-case DMD to allow the package keyword to be used here. I know D likes to abuse a keyword for multiple things (hello Mr. Static!), but I think we could live with it.
>


March 30, 2012
On 3/30/12, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16

Btw, I bet with the help of hackers like e.g. Kenji Hara we'll have this implemented in a matter of days (if it gets accepted). Compare that to having a C++ committee that would spend the next 5 years writing a 100-page spec on what is or isn't a package, heheh. Didn't Bjarne say on Going Native that he doesn't really know what a module is or should be? He should try D sometime. ;)
March 30, 2012
On Friday, March 30, 2012 09:46:19 Andrei Alexandrescu 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!

The first part with package.d seems like a good idea and certainly affects some of what I've been doing with std.datetime. In order to split it right now, you need a new package name, leaving the original for importing everything, and this provides a better way of dealing with that.

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);

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. 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.

I'd propose that we make it so that if a module publicly imports another module, then you could treat it as if it were in that module. So, because std.datetime.package publicly imports std.datetime.systime, you could use std.datetime.SysTime instead of std.datetime.systime.SysTime. The compiler would need to realize that they're exactly the same symbol (we've had bugs relating to importing with : and the like which ended up creating new symbols, and we don't want that here), but that shouldn't be all that hard. That gives you control over which symbols are able to be treated as if they were in a given package rather than affecting everything indiscriminitely (and if you use : with public imports, it should then be possible, to restrict it to the _exact_ set of symbols that you want if you don't want all of the symbols to be treated as if they were in that module).

Another question is how this affects the documentation. Does package.d generate a page just like the other modules do? The lack of a module declaration could make that difficult (not impossible, but it would probably require changes to ddoc in addition to the module stuff). Also, does that page get treated in any special manner in how the documentation is laid out, because it's for the package as a whole (probably more of a site question than a ddoc one though)? I'd like to be able to have a page describing the package as a whole for std.datetime in addition to having the individual pages rather than just splitting it up, and leaving the programmer to read each of the individual pages with no overview. And I think that however package.d works, it needs to enable that.

- Jonathan M Davis
« First   ‹ Prev
1 2 3 4 5 6 7 8 9 10 11