View mode: basic / threaded / horizontal-split · Log in · Help
October 16, 2012
Re: Import improvement
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?
October 16, 2012
Re: Import improvement
>> 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
October 16, 2012
Re: Import improvement
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.
October 16, 2012
Re: Import improvement
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
October 16, 2012
Re: Import improvement
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.
October 16, 2012
Re: Import improvement
> 
> 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".
October 16, 2012
Re: Import improvement
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.
October 16, 2012
Re: Import improvement
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.
October 16, 2012
Re: Import improvement
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
October 16, 2012
Re: Import improvement
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.
1 2 3 4
Top | Discussion index | About this forum | D home