October 16, 2012 Re: Import improvement | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sönke Ludwig | 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 |
October 16, 2012 Re: Import improvement | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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
|
October 16, 2012 Re: Import improvement | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | 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.
|
October 17, 2012 Re: Import improvement | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sönke Ludwig | 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 |
October 17, 2012 Re: Import improvement | ||||
---|---|---|---|---|
| ||||
Posted in reply to 1100110 | 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
|
October 17, 2012 Re: Import improvement | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | 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
|
October 17, 2012 Re: Import improvement | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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.
|
October 18, 2012 Re: Import improvement | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Alexander | 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.
|
October 19, 2012 Re: Import improvement | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | 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 |
October 19, 2012 Re: Import improvement | ||||
---|---|---|---|---|
| ||||
Posted in reply to Marco Leise | 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 |
Copyright © 1999-2021 by the D Language Foundation