Modules named "object" with DMD 0.153

[Chris Nicholson-Sauls]

Hasan Aljudy wrote:
> Chris Nicholson-Sauls wrote:
> 
>> It isn't perfect, but it appears there is now a way to have modules 
>> named 'object' or at least according to a cheap little test I just 
>> ran.  The trick is to explicitly import 'object' in your own 
>> 'object'.  Let me show you what I mean:
>>
>> # module test;
>> #
>> # private import std.stdio ;
>> #
>> # private import foo.object ;
>> #
>> # void main () {
>> #   FooObject foo = new FooObject ;
>> #   writefln("%s", foo.toString);
>> # }
>>
>> # module foo.object;
>> #
>> # import object;
>> #
>> # class FooObject : Object {
>> #   public char[] toString () { return "<<FooObject>>"c; }
>> # }
>>
>> This compiles and runs fine for me, DMD 0.153 on Windows.
>>
>> -- Chris Nicholson-Sauls
> 
> 
> but this module is foo.object, which is totally different from object.
> 
> There shouldn't be a problem with creating a module foo.object, it 
> wouldn't conflict with object anyway. At least that's what I think.

It didn't use to matter.  A project of mine, codename Lyra, had a module named 
"lyra.db.object" which caused the problem to show itself.  I ended up renaming it to 
"lyra.db.lobject" (note the "l" prefix) to get around it, and renamed the contained class 
to "LObject" as well.

I would not expect having a local (ie, not under any package at all) "object" module to 
/EVER/ work, because the standard library "object" module is not under any package, 
therefore the two will /ALWAYS/ conflict in name, no matter what one might do.  (I still 
say the solution is to move the standard "object" to "std.object" and be happy.)

-- Chris Nicholson-Sauls