Found the problem, and it was completely irrelevant to everything -- I had all of the environment variables set up correctly right from the very beginning.

The problem?  The object.d file in my project folder was overriding object.d in the Phobos directory.  I renamed it to "gameobject.d" and everything works peachy-keen now.

(I noticed this because after I uncommented some code in object.d, I started getting some errors in that file while I tried to compile the file test.d (which I posted) in the same folder.  test.d does not import object.d at all, so something had to be automatically importing it.  That's when it clicked.)

This kind of name clash should probably be documented... =)

--JT

On Thu, 6 Apr 2006 06:10:30 +0000 (UTC), Jeremy Gibson <jtgibson telus net Jeremy_member@pathlink.com> wrote:
> Found the problem, and it was completely irrelevant to everything -- I had all
> of the environment variables set up correctly right from the very beginning.
>
> The problem?  The object.d file in my project folder was overriding object.d in
> the Phobos directory.  I renamed it to "gameobject.d" and everything works
> peachy-keen now.
>
> (I noticed this because after I uncommented some code in object.d, I started
> getting some errors in that file while I tried to compile the file test.d (which
> I posted) in the same folder.  test.d does not import object.d at all, so
> something had to be automatically importing it.  That's when it clicked.)
>
> This kind of name clash should probably be documented... =)

Ahh, of course. Yeah, at least one other person has had this exact same problem.

At the very least it should be documented. The compiler could error on compiling object.d, and/or refuse to create an object.o and/or refuse to link/see any object.o which is not in the main directory.

(cross posted to bugs, not sure if it needs a bugzilla entry?)

Regan

Regan Heath wrote:
> On Thu, 6 Apr 2006 06:10:30 +0000 (UTC), Jeremy Gibson <jtgibson telus net Jeremy_member@pathlink.com> wrote:
>> Found the problem, and it was completely irrelevant to everything -- I had all
>> of the environment variables set up correctly right from the very beginning.
>>
>> The problem?  The object.d file in my project folder was overriding object.d in
>> the Phobos directory.  I renamed it to "gameobject.d" and everything works
>> peachy-keen now.
>>
>> (I noticed this because after I uncommented some code in object.d, I started
>> getting some errors in that file while I tried to compile the file test.d (which
>> I posted) in the same folder.  test.d does not import object.d at all, so
>> something had to be automatically importing it.  That's when it clicked.)
>>
>> This kind of name clash should probably be documented... =)
> 
> Ahh, of course. Yeah, at least one other person has had this exact same problem.
> 
> At the very least it should be documented. The compiler could error on compiling object.d, and/or refuse to create an object.o and/or refuse to link/see any object.o which is not in the main directory.
> 
> (cross posted to bugs, not sure if it needs a bugzilla entry?)

Definitely. He got an internal compiler error!

Regan Heath wrote:
> On Thu, 6 Apr 2006 06:10:30 +0000 (UTC), Jeremy Gibson <jtgibson telus net Jeremy_member@pathlink.com> wrote:
>> Found the problem, and it was completely irrelevant to everything -- I had all
>> of the environment variables set up correctly right from the very beginning.
>>
>> The problem?  The object.d file in my project folder was overriding object.d in
>> the Phobos directory.  I renamed it to "gameobject.d" and everything works
>> peachy-keen now.
>>
>> (I noticed this because after I uncommented some code in object.d, I started
>> getting some errors in that file while I tried to compile the file test.d (which
>> I posted) in the same folder.  test.d does not import object.d at all, so
>> something had to be automatically importing it.  That's when it clicked.)
>>
>> This kind of name clash should probably be documented... =)
> 
> Ahh, of course. Yeah, at least one other person has had this exact same problem.
> 
> At the very least it should be documented. The compiler could error on compiling object.d, and/or refuse to create an object.o and/or refuse to link/see any object.o which is not in the main directory.

For what it's worth, I've run into this with Ares before.  DMD requires certain class definitions to be in object.d.  If it needs them and they aren't there, the compiler crashes.  But this should be reported, as the correct behavior would be to terminate with a helpful message.


Sean

Sean Kelly wrote:
> Regan Heath wrote:
> 
>> On Thu, 6 Apr 2006 06:10:30 +0000 (UTC), Jeremy Gibson <jtgibson telus net Jeremy_member@pathlink.com> wrote:
>>
>>> Found the problem, and it was completely irrelevant to everything -- I had all
>>> of the environment variables set up correctly right from the very beginning.
>>>
>>> The problem?  The object.d file in my project folder was overriding object.d in
>>> the Phobos directory.  I renamed it to "gameobject.d" and everything works
>>> peachy-keen now.
>>>
>>> (I noticed this because after I uncommented some code in object.d, I started
>>> getting some errors in that file while I tried to compile the file test.d (which
>>> I posted) in the same folder.  test.d does not import object.d at all, so
>>> something had to be automatically importing it.  That's when it clicked.)
>>>
>>> This kind of name clash should probably be documented... =)
>>
>>
>> Ahh, of course. Yeah, at least one other person has had this exact same problem.
>>
>> At the very least it should be documented. The compiler could error on compiling object.d, and/or refuse to create an object.o and/or refuse to link/see any object.o which is not in the main directory.
> 
> 
> For what it's worth, I've run into this with Ares before.  DMD requires certain class definitions to be in object.d.  If it needs them and they aren't there, the compiler crashes.  But this should be reported, as the correct behavior would be to terminate with a helpful message.
> 
> 
> Sean

DMD's phobos should rename the object module class to something inconspicuous like '_d_object' or something to avoid naming conflicts with new programmers. :) (I just thought naming conflicts with new programmers was kinda funny)

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O M--@ V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e h>--->++ r+++ y+++
------END GEEK CODE BLOCK------

James Dunne

James Dunne wrote:
> Sean Kelly wrote:
> 
>> Regan Heath wrote:
>>
>>> On Thu, 6 Apr 2006 06:10:30 +0000 (UTC), Jeremy Gibson <jtgibson telus net Jeremy_member@pathlink.com> wrote:
>>>
>>>> Found the problem, and it was completely irrelevant to everything -- I had all
>>>> of the environment variables set up correctly right from the very beginning.
>>>>
>>>> The problem?  The object.d file in my project folder was overriding object.d in
>>>> the Phobos directory.  I renamed it to "gameobject.d" and everything works
>>>> peachy-keen now.
>>>>
>>>> (I noticed this because after I uncommented some code in object.d, I started
>>>> getting some errors in that file while I tried to compile the file test.d (which
>>>> I posted) in the same folder.  test.d does not import object.d at all, so
>>>> something had to be automatically importing it.  That's when it clicked.)
>>>>
>>>> This kind of name clash should probably be documented... =)
>>>
>>>
>>>
>>> Ahh, of course. Yeah, at least one other person has had this exact same problem.
>>>
>>> At the very least it should be documented. The compiler could error on compiling object.d, and/or refuse to create an object.o and/or refuse to link/see any object.o which is not in the main directory.
>>
>>
>>
>> For what it's worth, I've run into this with Ares before.  DMD requires certain class definitions to be in object.d.  If it needs them and they aren't there, the compiler crashes.  But this should be reported, as the correct behavior would be to terminate with a helpful message.
>>
>>
>> Sean
> 
> 
> DMD's phobos should rename the object module class to something inconspicuous like '_d_object' or something to avoid naming conflicts with new programmers. :) (I just thought naming conflicts with new programmers was kinda funny)
> 

I think it should just go into std package, making it std.object
This way it'll be very hard to make the above mentioned mistake without knowing what's going on.

Hasan Aljudy wrote:
> James Dunne wrote:
> 
>> Sean Kelly wrote:
>>
>>> Regan Heath wrote:
>>>
>>>> On Thu, 6 Apr 2006 06:10:30 +0000 (UTC), Jeremy Gibson <jtgibson telus net Jeremy_member@pathlink.com> wrote:
>>>>
>>>>> Found the problem, and it was completely irrelevant to everything -- I had all
>>>>> of the environment variables set up correctly right from the very beginning.
>>>>>
>>>>> The problem?  The object.d file in my project folder was overriding object.d in
>>>>> the Phobos directory.  I renamed it to "gameobject.d" and everything works
>>>>> peachy-keen now.
>>>>>
>>>>> (I noticed this because after I uncommented some code in object.d, I started
>>>>> getting some errors in that file while I tried to compile the file test.d (which
>>>>> I posted) in the same folder.  test.d does not import object.d at all, so
>>>>> something had to be automatically importing it.  That's when it clicked.)
>>>>>
>>>>> This kind of name clash should probably be documented... =)
>>>>
>>>>
>>>>
>>>>
>>>> Ahh, of course. Yeah, at least one other person has had this exact same problem.
>>>>
>>>> At the very least it should be documented. The compiler could error on compiling object.d, and/or refuse to create an object.o and/or refuse to link/see any object.o which is not in the main directory.
>>>
>>>
>>>
>>>
>>> For what it's worth, I've run into this with Ares before.  DMD requires certain class definitions to be in object.d.  If it needs them and they aren't there, the compiler crashes.  But this should be reported, as the correct behavior would be to terminate with a helpful message.
>>>
>>>
>>> Sean
>>
>>
>>
>> DMD's phobos should rename the object module class to something inconspicuous like '_d_object' or something to avoid naming conflicts with new programmers. :) (I just thought naming conflicts with new programmers was kinda funny)
>>
> 
> I think it should just go into std package, making it std.object
> This way it'll be very hard to make the above mentioned mistake without knowing what's going on.

I'm all for this solution, for two reasons.  Reason 1, I've personally had a project where I had a class whose most obvious natural name would be Object.  Of course, I ended up calling it LObject, and renaming all its compliments with the L* prefix as well, for consistancy.  It would've been nice not to have to.  Reason 2, it solves the problem of what to do if I actually want to explicitly refer to the generic Object: just call it std.object.Object (perhaps with an alias of _D_Object?)

-- Chris Nicholson-Sauls

Hasan Aljudy wrote:
> James Dunne wrote:
>> Sean Kelly wrote:
>>
>>> Regan Heath wrote:

<snip>

>>>> At the very least it should be documented. The compiler could error on compiling object.d, and/or refuse to create an object.o and/or refuse to link/see any object.o which is not in the main directory.
>>>
>>>
>>>
>>> For what it's worth, I've run into this with Ares before.  DMD requires certain class definitions to be in object.d.  If it needs them and they aren't there, the compiler crashes.  But this should be reported, as the correct behavior would be to terminate with a helpful message.
>>>
>>>
>>> Sean
>>
>>
>> DMD's phobos should rename the object module class to something inconspicuous like '_d_object' or something to avoid naming conflicts with new programmers. :) (I just thought naming conflicts with new programmers was kinda funny)
>>
> 
> I think it should just go into std package, making it std.object
> This way it'll be very hard to make the above mentioned mistake without knowing what's going on.

I asked Walter to put object into std.object a long time ago. I don't think he ever responded to that request (i.e. if there's a reason why he won't do this, I don't remember what it is).

I also think that gcstats.d, unittest.d, crc32.d, etc. should be moved into the std module (or into "internal" or "etc").

-- 
jcc7