On 16 October 2012 02:39, 1100110 <0b1100110@gmail.com> wrote:

> On Mon, 15 Oct 2012 13:38:31 -0500, Chris Nicholson-Sauls < ibisbasenji@gmail.com> wrote:
>
>  On Monday, 15 October 2012 at 15:37:06 UTC, Andrei Alexandrescu wrote:
>>
>>> I don't think imports from a specific package have been considered.
>>>
>>> In my personal opinion, imports are a necessary evil and it's sort of a bummer that the most accessible place in any source file - the top lines - is occupied by the crappy legal disclaimer (which, after having talked to a lawyer, I always put at the bottom since being at the top is not a requirement), and the litany of imports that the module is using. I'd make all imports local or put them at the bottom of the file if it weren't too much of a shock to others.
>>>
>>> Three remarks on this particular problem.
>>>
>>> 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 is a common practice (usually all.di) but perhaps it could help to establish an official convention.  Nothing in the language, just the styleguide.  (I know this has already come up and been discussed.)
>>
>
> 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?

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


-- 
Shut up, Opera

I like the idea of being able to either import a module, or package, with being able to choose what you want to import from it.

Something like
import std.stdio : writeln; (already exists)
import std : stdio, algorithm;
or just 'import std', though for something like std that would of course not be recommended. For smaller packages, such as std.datetime though, it would be useful.

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.

-- 
/Jacob Carlborg

Am 10/16/2012 2:10 AM, schrieb Peter Alexander:
> On Monday, 15 October 2012 at 23:43:53 UTC, 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.
> 
> It's cute, but I think it is terribly misleading. I wouldn't recommend that to anyone.

I agree, in vibe.d it's just a little pun on the name, but in general it could of course be mistaken as a file name.

I've used pack.pack instead of pack.all or pack._ in the past, but somehow all of them are kind of ugly without being able to just say 'pack', as in the DIP.

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

Strong words aside, let me tell you that the "vibe.d" import is just a small convenience for quick projects, so that you don't have to write yuor own main() function - something that in general appeals to quite a few people when using web frameworks in dynamic languages.

In this context it was just a funny idea to name it like this (named after the project, not to make it look like a file, of course) and make it a kind of unique trait. However, this is by no means a pattern. The module that imports everything is "vibe.vibe".

On 16 October 2012 11:22, Sönke Ludwig <sludwig@outerproduct.org> wrote:

> >
> > 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?
>
> Strong words aside, let me tell you that the "vibe.d" import is just a small convenience for quick projects, so that you don't have to write yuor own main() function - something that in general appeals to quite a few people when using web frameworks in dynamic languages.
>
> In this context it was just a funny idea to name it like this (named after the project, not to make it look like a file, of course) and make it a kind of unique trait. However, this is by no means a pattern. The module that imports everything is "vibe.vibe".
>

What's wrong with the reasonably established '_' module though? Trying to
make it appear like a source filename is a deception. That may confuse the
programmer.
That said, I didn't realise the project incorporated '.d' in the project
name. I was under the impression it was being carried to other projects too
that may not share the same naming pun.

Am 10/16/2012 1:53 PM, schrieb Manu:
> 
> What's wrong with the reasonably established '_' module though? Trying
> to make it appear like a source filename is a deception. That may
> confuse the programmer.
> (...)

Again, it has *not* the same meaning as a _.d module. It's just a single, very special, module. I totally agree with the possible confusion in general.

But speaking of '_' (and I have to admit that I didn't look at that many projects) - I've never seen that in the wild. And (IMO) "import something._" also looks quite awkward and non-self-explanatory, much more than either "something.all", "something.*" or "something.something". Making it just into "import somthing;" with some compiler support would of course change the game.

Leaving all that aside, in larger projects I always just import single modules and rarely use public imports, only when there are compelling reasons. So I would definitely welcome something along the lines of what you proposed.

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

> But speaking of '_' (and I have to admit that I didn't look at that many
> projects) - I've never seen that in the wild. And (IMO) "import
> something._" also looks quite awkward and non-self-explanatory, much
> more than either "something.all", "something.*" or
> "something.something". Making it just into "import somthing;" with some
> compiler support would of course change the game.

"import something;", how would you know if it's a module or a package? I really would like to be able to use "import something.*" but the compiler doesn't support it, so .all/._ is the best we can do for now.

-- 
/Jacob Carlborg

Am 10/16/2012 3:11 PM, schrieb Jacob Carlborg:
> On 2012-10-16 14:36, Sönke Ludwig wrote:
> 
>> But speaking of '_' (and I have to admit that I didn't look at that many projects) - I've never seen that in the wild. And (IMO) "import something._" also looks quite awkward and non-self-explanatory, much more than either "something.all", "something.*" or "something.something". Making it just into "import somthing;" with some compiler support would of course change the game.
> 
> "import something;", how would you know if it's a module or a package? I really would like to be able to use "import something.*" but the compiler doesn't support it, so .all/._ is the best we can do for now.
> 

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

http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16

It would definitely be good to have a decistion if the compiler will support it at some point to not start naming all those modules all.d only to dicover later that the compiler wants to have _.d.