Re: Import improvement
Am Wed, 17 Oct 2012 08:36:11 +0200 schrieb Jacob Carlborg d...@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
Re: Import improvement
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
Re: Import improvement
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.
Re: Import improvement
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
Re: Import improvement
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
Re: Import improvement
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
Re: Import improvement
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.
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
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.
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.
Re: Import improvement
On 16 October 2012 11:22, Sönke Ludwig slud...@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.
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.
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
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.
Re: Import improvement
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
Re: Import improvement
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
Re: Import improvement
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.
Re: Import improvement
Le 15/10/2012 14:43, Manu a écrit : So I'm getting sick of this in my files: module stache.states.ingamestate; import fuji.filesystem; import fuji.render; import fuji.matrix; import fuji.material; import fuji.primitive; import fuji.system; import fuji.font; import std.xml; import std.string; import std.conv; import std.random; import std.algorithm; import stache.battlecamera; import stache.i.statemachine; import stache.game; import stache.util.eventtypes; import stache.i.entity; import stache.entity.combatant; import stache.entity.paimei; import stache.thinkers.localplayer; import stache.thinkers.nullthinker; import stache.i.collider; import stache.sound.soundset; import stache.sound.music; This is obviously silly. I know this could be improved with some care, more liberal public imports (dangerous, you risk ending up with EVERYTHING as public import if it sticks as a standard convention), better maintained dependencies... but it's not realistic in a production environment. That sort of maintenance just never happens. I suggest expanding the selective import mechanism to extend to modules, not just functions within a module, eg: module stache.states.ingamestate; import fuji: filesystem, render, matrix, material, primitive, system, font; import std: xml, string, conv, random, algorithm; import stache: game, battlecamera; import stache.i: statemachine, entity, collider; import stache.entity: combatant, paimei; import stache.thinkers: localplayer, nullthinker; import stache.sound: soundset, music; import stache.util.eventtypes; This is much better! Saved ~25 lines of import rubbish, and it also enforces logical grouping; individual import statements tends to lead to related submodules being distanced from eachother, this way, they appear on the same line. Surely this has been considered before. Any reasons it's not supported? It make sense.
Re: Import improvement
On Monday, 15 October 2012 at 12:43:59 UTC, Manu wrote:
Surely this has been considered before. Any reasons it's not
supported?
Yes, it has been considered before. There is an enhancement from
ages ago in bugzilla.
http://d.puremagic.com/issues/show_bug.cgi?id=3603
The syntax you proposed doesn't work, because it conflicts with
selective imports:
===[std.d]===
module std;
void stdio() {}
===[test.d]===
import std : stdio;
Does that import the stdio function from module std, or the
module std.stdio?
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.
Re: Import improvement
On 15 October 2012 16:02, Peter Alexander peter.alexander...@gmail.comwrote:
On Monday, 15 October 2012 at 12:43:59 UTC, Manu wrote:
Surely this has been considered before. Any reasons it's not supported?
Yes, it has been considered before. There is an enhancement from ages ago
in bugzilla.
http://d.puremagic.com/issues/**show_bug.cgi?id=3603http://d.puremagic.com/issues/show_bug.cgi?id=3603
The syntax you proposed doesn't work, because it conflicts with selective
imports:
===[std.d]===
module std;
void stdio() {}
===[test.d]===
import std : stdio;
Does that import the stdio function from module std, or the module
std.stdio?
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.
Awesome. Well, just throwing it out there... any mechanism by which this is
possible will suit me!
Re: Import improvement
Le 15/10/2012 15:02, Peter Alexander a écrit :
On Monday, 15 October 2012 at 12:43:59 UTC, Manu wrote:
Surely this has been considered before. Any reasons it's not supported?
Yes, it has been considered before. There is an enhancement from ages
ago in bugzilla.
http://d.puremagic.com/issues/show_bug.cgi?id=3603
The syntax you proposed doesn't work, because it conflicts with
selective imports:
===[std.d]===
module std;
void stdio() {}
===[test.d]===
import std : stdio;
Does that import the stdio function from module std, or the module
std.stdio?
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.
I don't think import should make the difference between packages/modules
and module content.
The example you take is only ambiguous if std is both a package and a
module which isn't allowed anyway now. It is a point on which people are
willing to advance already (Andrei have made a proposal about it).
I'm against introducing more new syntax to import. import is already a
complex beast.
Re: Import improvement
deadalnix: I don't think import should make the difference between packages/modules and module content. This is acceptable only if then it imports the module names only. It means that later you must write stdio.writeln(). I'm against introducing more new syntax to import. import is already a complex beast. The suggested syntax import std.(stdio, xml, algorithm); is probably sub-optimal, and maybe better solutions exist. But in most cases more syntax is way better than foggy/messy semantics. Bye, bearophile
Re: Import improvement
On Monday, 15 October 2012 at 13:46:43 UTC, deadalnix wrote: I don't think import should make the difference between packages/modules and module content. The example you take is only ambiguous if std is both a package and a module which isn't allowed anyway now. It is a point on which people are willing to advance already (Andrei have made a proposal about it). My example with module std works as of DMD 2.060, and I can't see anything in the spec that says it is disallowed, or are you saying that it has been agreed that it will be disallowed in the future? I'm against introducing more new syntax to import. import is already a complex beast. I agree, but I also don't like the idea of using the same syntax to mean two different things. import foo : bar, baz; Is this selectively importing symbols or is it importing two modules? This is mildly confusing for the programmer, and complicates parsing.
Re: Import improvement
On 2012-43-15 14:10, Manu turkey...@gmail.com wrote: module stache.states.ingamestate; import fuji: filesystem, render, matrix, material, primitive, system, font; import std: xml, string, conv, random, algorithm; import stache: game, battlecamera; import stache.i: statemachine, entity, collider; import stache.entity: combatant, paimei; import stache.thinkers: localplayer, nullthinker; import stache.sound: soundset, music; import stache.util.eventtypes; Looks nice. Much better than before, certainly. Now, i'm wondering, you /do/ know this is possible, right: import fuji.filesystem, fuji.render, fuji.matrix, fuji.material, fuji.primitive, fuji.system, fuji.font; import std.xml, std.string, std.conv, std.random, std.algorithm; import stache.game, stache.battlecamera; import stache.i.statemachine, stache.i.entity, stache.i.collider; import stache.entity.combatant, stache.entity.paimei; import stache.thinkers.localplayer, stache.thinkers.nullthinker; import stache.sound.soundset, stache.sound.music; import stache.util.eventtypes; Not quite as neat, but still a lot better, methinks. -- Simen
Re: Import improvement
On Monday, 15 October 2012 at 14:20:48 UTC, Peter Alexander wrote: On Monday, 15 October 2012 at 13:46:43 UTC, deadalnix wrote: I don't think import should make the difference between packages/modules and module content. The example you take is only ambiguous if std is both a package and a module which isn't allowed anyway now. It is a point on which people are willing to advance already (Andrei have made a proposal about it). My example with module std works as of DMD 2.060, and I can't see anything in the spec that says it is disallowed, or are you saying that it has been agreed that it will be disallowed in the future? I'm against introducing more new syntax to import. import is already a complex beast. I agree, but I also don't like the idea of using the same syntax to mean two different things. import foo : bar, baz; Is this selectively importing symbols or is it importing two modules? This is mildly confusing for the programmer, and complicates parsing. And what about import foo : bar, .baz; where .baz is module
Re: Import improvement
On 10/15/12 8:43 AM, Manu wrote: So I'm getting sick of this in my files: [snip litany of imports] This is obviously silly. Agreed. I know this could be improved with some care, more liberal public imports (dangerous, you risk ending up with EVERYTHING as public import if it sticks as a standard convention), better maintained dependencies... but it's not realistic in a production environment. That sort of maintenance just never happens. I suggest expanding the selective import mechanism to extend to modules, not just functions within a module, eg: module stache.states.ingamestate; import fuji: filesystem, render, matrix, material, primitive, system, font; import std: xml, string, conv, random, algorithm; import stache: game, battlecamera; import stache.i: statemachine, entity, collider; import stache.entity: combatant, paimei; import stache.thinkers: localplayer, nullthinker; import stache.sound: soundset, music; import stache.util.eventtypes; This is much better! Saved ~25 lines of import rubbish, and it also enforces logical grouping; individual import statements tends to lead to related submodules being distanced from eachother, this way, they appear on the same line. Surely this has been considered before. Any reasons it's not supported? 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. 2. The import declaration accepts a list of modules, and several may be on one line. I think that's a significant positive difference from C, C++, or Go, all of which force one imported module per line. I always advocate imports from the same package in the same import declaration, ordered alphabetically: import fuji.filesystem, fuji.font, fuji.material, fuji.matrix, fuji.primitive, fuji.render, fuji.system; import std.algorithm, std.conv, std.random, std.string, std.xml; ... That makes the existing system much more palatable. 3. I think local imports are currently underutilized. It would be interesting to see what kind of project dynamics they enable. Andrei
Re: Import improvement
On 15 October 2012 17:29, Simen Kjaeraas simen.kja...@gmail.com wrote: On 2012-43-15 14:10, Manu turkey...@gmail.com wrote: module stache.states.ingamestate; import fuji: filesystem, render, matrix, material, primitive, system, font; import std: xml, string, conv, random, algorithm; import stache: game, battlecamera; import stache.i: statemachine, entity, collider; import stache.entity: combatant, paimei; import stache.thinkers: localplayer, nullthinker; import stache.sound: soundset, music; import stache.util.eventtypes; Looks nice. Much better than before, certainly. Now, i'm wondering, you /do/ know this is possible, right: import fuji.filesystem, fuji.render, fuji.matrix, fuji.material, fuji.primitive, fuji.system, fuji.font; import std.xml, std.string, std.conv, std.random, std.algorithm; import stache.game, stache.battlecamera; import stache.i.statemachine, stache.i.entity, stache.i.collider; import stache.entity.combatant, stache.entity.paimei; import stache.thinkers.localplayer, stache.thinkers.nullthinker; import stache.sound.soundset, stache.sound.music; import stache.util.eventtypes; I didn't know that was possible _ Cheers for the protip!
Re: Import improvement
On 10/15/12 11:46 AM, Manu wrote: On 15 October 2012 17:29, Simen Kjaeraas simen.kja...@gmail.com mailto:simen.kja...@gmail.com wrote: import fuji.filesystem, fuji.render, fuji.matrix, fuji.material, fuji.primitive, fuji.system, fuji.font; import std.xml, std.string, std.conv, std.random, std.algorithm; import stache.game, stache.battlecamera; import stache.i.statemachine, stache.i.entity, stache.i.collider; import stache.entity.combatant, stache.entity.paimei; import stache.thinkers.localplayer, stache.thinkers.nullthinker; import stache.sound.soundset, stache.sound.music; import stache.util.eventtypes; I didn't know that was possible _ Cheers for the protip! I think our documentation examples could be changed to use multiple imports systematically. Andrei
Re: Import improvement
On 2012-10-15 14:43, Manu wrote: This is obviously silly. I know this could be improved with some care, more liberal public imports (dangerous, you risk ending up with EVERYTHING as public import if it sticks as a standard convention), better maintained dependencies... but it's not realistic in a production environment. That sort of maintenance just never happens. I suggest expanding the selective import mechanism to extend to modules, not just functions within a module, eg: module stache.states.ingamestate; import fuji: filesystem, render, matrix, material, primitive, system, font; import std: xml, string, conv, random, algorithm; import stache: game, battlecamera; import stache.i: statemachine, entity, collider; import stache.entity: combatant, paimei; import stache.thinkers: localplayer, nullthinker; import stache.sound: soundset, music; import stache.util.eventtypes; This is much better! Saved ~25 lines of import rubbish, and it also enforces logical grouping; individual import statements tends to lead to related submodules being distanced from eachother, this way, they appear on the same line. Surely this has been considered before. Any reasons it's not supported? Shouldn't it be possible to create a mixin that does this? mixin require(std, xml, string); Something like that. But you would still need to import the require function. -- /Jacob Carlborg
Re: Import improvement
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.) 2. The import declaration accepts a list of modules, and several may be on one line. I think that's a significant positive difference from C, C++, or Go, all of which force one imported module per line. I always advocate imports from the same package in the same import declaration, ordered alphabetically: import fuji.filesystem, fuji.font, fuji.material, fuji.matrix, fuji.primitive, fuji.render, fuji.system; import std.algorithm, std.conv, std.random, std.string, std.xml; ... That makes the existing system much more palatable. I've done this very thing for eons, and yes you are quite right! (Although my formatting is different, but I digress.) That said, I think the OP still has a valid, even quite strong point. Consider, in comparison to your sample: import fuji.( filesystem, font, material, matrix, primitive, render, system ); import std.( algorithm, conv, random, string, xml ); Certainly less visual noise. An even *better* level of improvement comes if we provide an alternate and similar syntax for selective imports, so that they no longer have to be separated. import std.( algorithm, conv, random, xml, stdio:( write, writef, writefln ), string:( munch, splitLines, xformat, xsformat ) ); As for implementation, how difficult is it for the compiler to internally expand something like this into the traditional litany? 3. I think local imports are currently underutilized. It would be interesting to see what kind of project dynamics they enable. I can agree with this. -- Chris Nicholson-Sauls
Re: Import improvement
IMHO it should be IDE's job. When coding Java or C#, you select Fix imports and IDE automatically removes unused imports and adds new imports for undefined symbols. By the way, what about syntax like this: import std.*; would it make sense?
Re: Import improvement
On 2012-10-15, 19:13, Jacob Carlborg wrote: Shouldn't it be possible to create a mixin that does this? mixin require(std, xml, string); Something like that. But you would still need to import the require function. Put it in object.d, then. Still, I feel the language already has the required sugar in that one may import a list of modules. -- Simen
Re: Import improvement
On 2012-10-15, 20:52, JN wrote: IMHO it should be IDE's job. When coding Java or C#, you select Fix imports and IDE automatically removes unused imports and adds new imports for undefined symbols. By the way, what about syntax like this: import std.*; would it make sense? It sorta would, but creating an all.d file and importing std.all instead works just as fine. -- Simen
Re: Import improvement
On 15 October 2012 21:52, JN 666to...@wp.pl wrote: IMHO it should be IDE's job. When coding Java or C#, you select Fix imports and IDE automatically removes unused imports and adds new imports for undefined symbols. Can you name an (industry standard) IDE that works well with D? By the way, what about syntax like this: import std.*; would it make sense? In my case, I don't want to import everything.
Re: Import improvement
On Monday, 15 October 2012 at 19:15:44 UTC, Manu wrote: [...] In my case, I don't want to import everything. how about something along the lines of Pythons from X import Y, Z where X would specifically be a package, and Y and Z would be the modules imported. This should keep things simple for both programmer and compiler alike.
Re: Import improvement
On 2012-10-15 21:13, Simen Kjaeraas wrote: By the way, what about syntax like this: import std.*; would it make sense? It sorta would, but creating an all.d file and importing std.all instead works just as fine. I would really like to have this feature instead of having to manually create these all.d files. -- /Jacob Carlborg
Re: Import improvement
On Mon, 15 Oct 2012 13:38:31 -0500, Chris Nicholson-Sauls ibisbase...@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.
Re: Import improvement
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.
Re: Import improvement
On Mon, 15 Oct 2012 19:10:02 -0500, Peter Alexander peter.alexander...@gmail.com wrote: 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. How is it misleading? -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Import improvement
On 16 October 2012 02:39, 1100110 0b1100...@gmail.com wrote: On Mon, 15 Oct 2012 13:38:31 -0500, Chris Nicholson-Sauls ibisbase...@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?
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
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.
