DMD compiler choking? [Woohoo!]

[Chris Nicholson-Sauls]

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 at 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