www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Problems with objects and exceptions

reply Joey Peters <Joey_member pathlink.com> writes:
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?
Sep 07 2004
parent reply J C Calvarese <jcc7 cox.net> writes:
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/
Sep 07 2004
parent reply Joey Peters <Joey_member pathlink.com> writes:
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/
Sep 08 2004
parent reply J C Calvarese <jcc7 cox.net> writes:
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/
Sep 08 2004
parent Joey Peters <Joey_member pathlink.com> writes:
"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.
Sep 09 2004