I noticed that, when you make your own 'object.d' or 'exception.d' that it will confuse the compiler/linker with phobos'. It will throw symbol redefinitions at you when linking. Maybe the compiler is a bit too loose on what to import where? Also, I think the -of switch should allow paths, so that you don't have to do a strange chdir thing before you can get it to build in a directory you'd like it to build (debug/release). Is there also a way to 'not' link the phobos library? It also seems that, even though you define a module name at the top of sourcefiles, that when you have another sourcefile in the same path, it would still import it and use it as though it was local (not prefixing/being able to use the stuff you specified). Maybe you wanted it to work like that though?

Joey Peters wrote:
> I noticed that, when you make your own 'object.d' or 'exception.d' that it will
> confuse the compiler/linker with phobos'. It will throw symbol redefinitions at
> you when linking. Maybe the compiler is a bit too loose on what to import where?

As far as the name "object.d" goes, it's pretty much off-limits (and it's documented, too):

http://www.digitalmars.com/d/phobos.html#object
"This module is implicitly imported."

(I wonder if Walter could move object.d to internal.object or std.object or somewhere other than the root. That'd be nice...)

I'm not sure what your problem is with "exception.d". Is the module called "Exception" (which would conflict with class "Exception" in object.d)?


> Also, I think the -of switch should allow paths, so that you don't have to do a
> strange chdir thing before you can get it to build in a directory you'd like it
> to build (debug/release). Is there also a way to 'not' link the phobos library?

I'm not sure. You might be able to create an "empty" phobos.lib, but you're going to have to add back essential parts such as the garbage collector and typeinfo stuff. There'd be many hidden obstacles to doing this for sure.


> It also seems that, even though you define a module name at the top of
> sourcefiles, that when you have another sourcefile in the same path, it would
> still import it and use it as though it was local (not prefixing/being able to
> use the stuff you specified). Maybe you wanted it to work like that though?

I'm not sure I understand your request here. If you give an example of what you want to do, someone might be able to suggest a work-around to get closer to your target.


-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

In article <chlfdo$1qh$1@digitaldaemon.com>, J C Calvarese says...
>
>Joey Peters wrote:
>> I noticed that, when you make your own 'object.d' or 'exception.d' that it will confuse the compiler/linker with phobos'. It will throw symbol redefinitions at you when linking. Maybe the compiler is a bit too loose on what to import where?
>
>As far as the name "object.d" goes, it's pretty much off-limits (and it's documented, too):
>
>http://www.digitalmars.com/d/phobos.html#object
>"This module is implicitly imported."
>
>(I wonder if Walter could move object.d to internal.object or std.object or somewhere other than the root. That'd be nice...)
>
>I'm not sure what your problem is with "exception.d". Is the module called "Exception" (which would conflict with class "Exception" in object.d)?

I just made my own exception class, though, I put it in another module. I'm working on my own little stl'ish library so that's why. (also, this is probably part of the problem you did not understand later on)

>
>> Also, I think the -of switch should allow paths, so that you don't have to do a strange chdir thing before you can get it to build in a directory you'd like it to build (debug/release). Is there also a way to 'not' link the phobos library?
>
>I'm not sure. You might be able to create an "empty" phobos.lib, but you're going to have to add back essential parts such as the garbage collector and typeinfo stuff. There'd be many hidden obstacles to doing this for sure.

Is it legal to take those parts and pop them in?

>> It also seems that, even though you define a module name at the top of sourcefiles, that when you have another sourcefile in the same path, it would still import it and use it as though it was local (not prefixing/being able to use the stuff you specified). Maybe you wanted it to work like that though?
>
>I'm not sure I understand your request here. If you give an example of what you want to do, someone might be able to suggest a work-around to get closer to your target.

It isn't really a big problem, it's just how namespaces (as far as they're considered namespaces) work.

Imagine I have this as a directory root:

|-example.d
|-dragon
|- array.d
|- spawn.d

in array.d, I have:

module dragon.array;
class array { }

In spawn.d, I have:

module dragon.spawn;
private import array;
class spawn {
public:
array.array something; // <-
}

Let's say I want to import 'array' to the namespace with alias:

module dragon.spawn;
private import array;
alias array.array array; // <- nope

Eitherway, it seems that when you're using modules that have the same name of their respective file or class it contains, the compiler get's confused. What bothers me more is that you can't do:

module dragon.spawn;
private import array;
dragon.array.array myarray; // array.d still defined to be in dragon.array

Though, for now and later, it's probably best (and most logical) to only clutter module dragon. Modules aren't really perfect yet?

>-- 
>Justin (a/k/a jcc7)
>http://jcc_7.tripod.com/d/

Comments embedded...

Joey Peters wrote:
> In article <chlfdo$1qh$1@digitaldaemon.com>, J C Calvarese says...
> 
>>Joey Peters wrote:
>>
>>>I noticed that, when you make your own 'object.d' or 'exception.d' that it will
>>>confuse the compiler/linker with phobos'. It will throw symbol redefinitions at
>>>you when linking. Maybe the compiler is a bit too loose on what to import where?
>>
>>As far as the name "object.d" goes, it's pretty much off-limits (and it's documented, too):
>>
>>http://www.digitalmars.com/d/phobos.html#object
>>"This module is implicitly imported."
>>
>>(I wonder if Walter could move object.d to internal.object or std.object or somewhere other than the root. That'd be nice...)
>>
>>I'm not sure what your problem is with "exception.d". Is the module called "Exception" (which would conflict with class "Exception" in object.d)?
> 
> 
> I just made my own exception class, though, I put it in another module. I'm
> working on my own little stl'ish library so that's why. (also, this is probably
> part of the problem you did not understand later on)

You could probably use your own exception module is you named it like this:

mylib\exception.d:
  module mylib.exception;

and used it like this:
  import mylib.exception;

>>>Also, I think the -of switch should allow paths, so that you don't have to do a
>>>strange chdir thing before you can get it to build in a directory you'd like it
>>>to build (debug/release). Is there also a way to 'not' link the phobos library?
>>
>>I'm not sure. You might be able to create an "empty" phobos.lib, but you're going to have to add back essential parts such as the garbage collector and typeinfo stuff. There'd be many hidden obstacles to doing this for sure.
> 
> 
> Is it legal to take those parts and pop them in?

"Legal!" IANAL, but I doubt Walter would sue you. ;)

You shouldn't create your own phobos.lib unless you're feeling adventurous (and don't expect anyone to take your bug reports seriously if you're playing with your home-grown phobos.lib).

Still, it might be an interesting experiment.

>>>It also seems that, even though you define a module name at the top of
>>>sourcefiles, that when you have another sourcefile in the same path, it would
>>>still import it and use it as though it was local (not prefixing/being able to
>>>use the stuff you specified). Maybe you wanted it to work like that though?
>>
>>I'm not sure I understand your request here. If you give an example of what you want to do, someone might be able to suggest a work-around to get closer to your target.
> 
> 
> It isn't really a big problem, it's just how namespaces (as far as they're
> considered namespaces) work.
> 
> Imagine I have this as a directory root:
> 
> |-example.d
> |-dragon
> |- array.d
> |- spawn.d
> 
> in array.d, I have:
> 
> module dragon.array;
> class array { }

I don't know if it helps you, but many people follow a convention where they usually capitalize classes (e.g., "Array").

But I guess that's changing the subject...

> 
> In spawn.d, I have:
> 
> module dragon.spawn;
> private import array;
> class spawn {
> public:
> array.array something; // <-
> }
> 
> Let's say I want to import 'array' to the namespace with alias:
> 
> module dragon.spawn;
> private import array;
> alias array.array array; // <- nope

Have you tried this?

private import dragon.array;
alias dragon.array.array array;

(You might need to compile like this: "dmd array.d -c -I.." where the "-I.." flag bumps up to the parent directory for includes.)

> 
> Eitherway, it seems that when you're using modules that have the same name of
> their respective file or class it contains, the compiler get's confused. What
> bothers me more is that you can't do:

I'm getting confused with all of the array.array.array.array.array.array  repetition. ;)

> 
> module dragon.spawn;
> private import array;
Try: "private import dragon.array;" I think you're "mixing metaphors".

> dragon.array.array myarray; // array.d still defined to be in dragon.array
> 
> Though, for now and later, it's probably best (and most logical) to only clutter
> module dragon. Modules aren't really perfect yet?

Nothing in this world is perfect, but modules make pretty good sense to me. In the past, D's handling of modules was buggy, but they're a lot more solid today.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

>"Legal!" IANAL, but I doubt Walter would sue you. ;)
>
>You shouldn't create your own phobos.lib unless you're feeling adventurous (and don't expect anyone to take your bug reports seriously if you're playing with your home-grown phobos.lib).
>
>Still, it might be an interesting experiment.

More educational than useful (for anyone). :)

>I don't know if it helps you, but many people follow a convention where they usually capitalize classes (e.g., "Array").
>
>But I guess that's changing the subject...
>

Yeah I'm doing that now, looks a lot cleaner when using it in other projects too.

>> 
>> In spawn.d, I have:
>> 
>> module dragon.spawn;
>> private import array;
>> class spawn {
>> public:
>> array.array something; // <-
>> }
>> 
>> Let's say I want to import 'array' to the namespace with alias:
>> 
>> module dragon.spawn;
>> private import array;
>> alias array.array array; // <- nope
>
>Have you tried this?
>
>private import dragon.array;
>alias dragon.array.array array;
>
>(You might need to compile like this: "dmd array.d -c -I.." where the "-I.." flag bumps up to the parent directory for includes.)

Argh!

>Nothing in this world is perfect, but modules make pretty good sense to me. In the past, D's handling of modules was buggy, but they're a lot more solid today.

They seem to work good enough. Though sometimes it's confusing where to put some (header is a wrong word) files, especially when things tend to have the same name. Guess the best to do is use lowercase for module names, and uppercase - lowercase for classes.