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
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,
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,
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
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
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
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.
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
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
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,
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
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
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
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.
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;
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
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
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.
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
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
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,
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
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
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;
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,
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
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
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?
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
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
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
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
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
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
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
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
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.
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
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
42 matches
Mail list logo
