April 08, 2012
On Saturday, 7 April 2012 at 17:44:20 UTC, Jonathan M Davis wrote
>
> Like I said, some people do like to do it, but Eclipse doesn't like you to,
> and there are quite a few Java folks who argue that it's bad practice. I
> forget what the reasons were (maybe increased buld times due to pulling in
> more symbols or more issues with symbol conflicts - I don't recall), but I
> wasn't particularly convinced when I heard them. Regardless though, there's a
> definite contingent against importing with * in the Java community, and it was
> my understanding that that contigent was the majority of that community, but I
> don't know.
>
> - Jonathan M Davis

http://stackoverflow.com/questions/147454/why-is-using-a-wild-card-with-a-java-import-statement-bad

Their reasoning sounds more due to various packages reinventing
things or being poorly split than actual flaws with package
imports themselves. Besides, D already addresses the issues of
indicating which one you want, without the horribly long package
names that Java has. Seems to me their examples are more like
'import std.*' than 'import std.datetime.*'.
April 09, 2012
On Fri, 06 Apr 2012 20:25:23 -0400, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> DIP15 doesn't fix the explicit path problem though. You can't change
> std/algorithm.d into std/algorithm/ (with sorting.d, search.d, etc.) without
> breaking code. You could make std/algorithm.d publicly import std/alg/* and
> then DIP15 would allow you to import std.alg to get all of its sub-modules,
> but you're still forced to use a module to publicly import symbols as part of
> a migration path, and you can't split a module in place.

I think either you or I am missing something.

In DIP15, if you define std/algorithm/_.d, and then import std.algorithm, it imports std/algorithm/_.d, which then 1. publicly imports other modules, and 2. aliases symbols to the name std.algorithm.symbol.  At least, this is how I understand the intent.  It seems equivalent to me to the package.d proposal, it's just using _.d instead of package.d.

If you import std.algorithm.sorting, and try and use std.algorithm.sort, yes it will not work.  But this does not break existing code (which does not import std.algorithm.sorting), and I find it odd that we want to make std.algorithm.sort work if you don't import std.algorithm.

-Steve
April 09, 2012
On Monday, April 09, 2012 08:55:27 Steven Schveighoffer wrote:
> On Fri, 06 Apr 2012 20:25:23 -0400, Jonathan M Davis <jmdavisProg@gmx.com>
> 
> wrote:
> > DIP15 doesn't fix the explicit path problem though. You can't change
> > std/algorithm.d into std/algorithm/ (with sorting.d, search.d, etc.)
> > without
> > breaking code. You could make std/algorithm.d publicly import std/alg/*
> > and
> > then DIP15 would allow you to import std.alg to get all of its
> > sub-modules,
> > but you're still forced to use a module to publicly import symbols as
> > part of
> > a migration path, and you can't split a module in place.
> 
> I think either you or I am missing something.
> 
> In DIP15, if you define std/algorithm/_.d, and then import std.algorithm, it imports std/algorithm/_.d, which then 1. publicly imports other modules, and 2. aliases symbols to the name std.algorithm.symbol. At least, this is how I understand the intent. It seems equivalent to me to the package.d proposal, it's just using _.d instead of package.d.
> 
> If you import std.algorithm.sorting, and try and use std.algorithm.sort, yes it will not work. But this does not break existing code (which does not import std.algorithm.sorting), and I find it odd that we want to make std.algorithm.sort work if you don't import std.algorithm.

Okay. I reread DIP15 again. I guess that I scanned over it too quickly before and/or misremembered it. I had understood that it was proposing that importing std.algorithm where std.algorithm was a package would be the equivalent of importing std.algorithm.* in Java and that there were no extra files involved. So clearly, I've been misunderstanding things here.

So, yeah. DIP15 is basically the same as DIP16 except without the std.sort nonsense and the fact that it uses _.d instead of package.d. Using package.d has the advantage of package being a keyword, making it so that no one is going to accidentally create a module that will be treated specially, but it has the downside of likely requiring more special handling by the compiler. I don't really care which we pick though.

My main point though, misunderstandings aside, is that it would be _really_ nice to be able to split up  a package in place and that without an enhancement of some kind, we can't do  that without breaking code. DIP15 appears to fit the bill quite nicely in that regard though. The part of DIP16 which is really bad is the std.sort stuff which. Public importing combined with either the first part of DIP16 or with DIP15 seems to take care of the problem quite nicely.

- Jonathan M Davis
1 2 3 4 5 6 7 8 9 10 11
Next ›   Last »