On 2012-10-16 16:14, Sönke Ludwig wrote:

> The compiler has to walk the directory structure anyway. If it stops at
> a directory, it looks for _.d/package.d/... and uses that.

I was more thinking of the developer reading the code.

-- 
/Jacob Carlborg

On Monday, October 15, 2012 11:37:06 Andrei Alexandrescu wrote:
> 1. I expect large packages to introduce a module "all.di" or "_.di" to publicly import everything in the package. That could help some use cases.

It would be fantastic if we could get something like DIP15/16 implemented which made it possible to do

import my.pkg;

instead of

import my.pkg.all;

or

import my.pkg._;

or whatever folks have come up with. And everything's there already except for making it so that when my.pkg is a package, importing my.pkg then imports a specially-named package inside of my.pkg with whatever public imports you want to have when importing the entire package. I started looking into implementing it a while back but got sidetracked before I could get very far.

- Jonathan M Davis

Am 10/16/2012 6:55 PM, schrieb Jacob Carlborg:
> On 2012-10-16 16:14, Sönke Ludwig wrote:
> 
>> The compiler has to walk the directory structure anyway. If it stops at a directory, it looks for _.d/package.d/... and uses that.
> 
> I was more thinking of the developer reading the code.
> 

Ah OK, sorry. There is no direct way of course. But assuming that it semantically makes sense to import a package and because it's necessary to look at some kind of documentation before importing anything anyway, I guess that could be a tolerable shortcoming.

On 2012-10-16 20:39, Sönke Ludwig wrote:

> Ah OK, sorry. There is no direct way of course. But assuming that it
> semantically makes sense to import a package and because it's necessary
> to look at some kind of documentation before importing anything anyway,
> I guess that could be a tolerable shortcoming.

Yeah, I would still prefer "import foo.bar.*" though.

-- 
/Jacob Carlborg

On 10/15/12 9:30 PM, 1100110 wrote:
>>> I like what vibe.d did by having an import all file named d.d
>>>
>>> Therefore you can:
>>> import vibe.d;
>>>
>>> It's nice, it's clean, and I've blatantly stolen it for a few of my own
>>> projects.
>>>
>>
>> O_O .. That might be one of the worst things I've ever seen!
>> It doesn't even make sense. Is there actually a vibe.d file? And why
>> try to
>> make the import statement look like a source filename?
>
> There is a source/vibe/d.d file.
> The reason it is there is because vibe.d includes it's own main(),
> There is a source/vibe/vibe.d file, but that is there for you to roll
> your own main().
>
> Shrug. "import file.d;" <- actual name is file.d
> doesn't work, and it isn't designed to work like that. So unless you
> know nothing about how the import
> system works, it's not really a problem.
>
> And I would assume that it was done since the name of the project is
> "vibe.d".
>
> If this is the worst thing that you've seen, then I don't think you've
> seen golang.. Or javascript's underscore library...
> "_.each([1, 2, 3], function(num){ alert(num); });
> => alerts each number in turn...
> _.each({one : 1, two : 2, three : 3}, function(num, key){ alert(num); });
> => alerts each number in turn..."
>
> That might be one of the worst, most confusing things that I've seen.

Wondering what happens if one has a file called something.d.d and imports it as something.d.

Andrei

On 10/16/12 2:49 AM, Jacob Carlborg wrote:
> On 2012-10-16 02:10, Peter Alexander wrote:
>
>> It's cute, but I think it is terribly misleading. I wouldn't recommend
>> that to anyone.
>
> I agree. I'm using foo.bar._, that's the same used by Scala.

Sounds good. Arbitrary + precedent > arbitrary.

Andrei

On Wednesday, 17 October 2012 at 15:16:12 UTC, Andrei Alexandrescu wrote:
> On 10/16/12 2:49 AM, Jacob Carlborg wrote:
>> On 2012-10-16 02:10, Peter Alexander wrote:
>>
>>> It's cute, but I think it is terribly misleading. I wouldn't recommend
>>> that to anyone.
>>
>> I agree. I'm using foo.bar._, that's the same used by Scala.
>
> Sounds good. Arbitrary + precedent > arbitrary.
>
> Andrei

Let's be accurate here:
Meaningful >>> Arbitrary + precedent > arbitrary.

If I want to truly import an _entire_ package than both:
import package.all;
import package.*;
make sense/ meaningful.

If I want to have a special file that includes specific public imports for the package's public API than it should be called appropriately. e.g:
import package.api;

I've seen such usage of an "api" package in Google's Android platform for instance.

On 15/10/2012 14:02, Peter Alexander wrote:
> You could use something like this:
>
> import std.(stdio, xml, algorithm);
>
> Of course, there's many variations (square brackets, curly braces, no
> dot, no commas...) but it's all bikeshedding.

Personally I like:

import package std : stdio, xml, algorithm;

compare with:

import std.algorithm : sort, swap;

This has nice symmetry and is unambiguous.

Am Wed, 17 Oct 2012 08:36:11 +0200
schrieb Jacob Carlborg <doob@me.com>:

> On 2012-10-16 20:39, Sönke Ludwig wrote:
> 
> > Ah OK, sorry. There is no direct way of course. But assuming that it semantically makes sense to import a package and because it's necessary to look at some kind of documentation before importing anything anyway, I guess that could be a tolerable shortcoming.
> 
> Yeah, I would still prefer "import foo.bar.*" though.

Just an observation...

import fuji: filesystem, render, matrix, material, primitive, system, font; import std: xml, string, conv, random, algorithm;

...is very easy on the eyes. It gives you that natural "in package std, there are the modules xml, string, ..." representation without repeatedly stating "fuji." or "std.".

-- 
Marco

On 2012-10-19 09:22, Marco Leise wrote:

> Just an observation...
>
> import fuji: filesystem, render, matrix, material, primitive, system, font;
> import std: xml, string, conv, random, algorithm;
>
> ...is very easy on the eyes. It gives you that natural "in
> package std, there are the modules xml, string, ..."
> representation without repeatedly stating "fuji." or "std.".

I think both of these could be useful.

-- 
/Jacob Carlborg