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

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.

In article <e1i6gi$14oj$2@digitaldaemon.com>, Hasan Aljudy says...
>
>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.


I think the original problem was you cannot declare a class with the name Object

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

AgentOrange wrote:
> In article <e1i6gi$14oj$2@digitaldaemon.com>, Hasan Aljudy says...
> 
>>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.
> 
> 
> 
> I think the original problem was you cannot declare a class with the name Object
> 
> 
> 

You can, however, declare a class named foo.object.Object, or even just foo.Object.  You just have to be very careful about the declerations of other classes in modules that import your module declaring an "Object" class.  In other words, in any module importing "foo" (which declares "Object") you cannot declare "orphan" classes because they are actually silently declared as children of ".Object".  Now, it is possible that one could now do this:

# module bar;
#
# private import foo; // declares class Object
#
# alias foo.Object FObject ;
# alias    .Object OBJECT  ; // note the "."
#
# class BarClass : OBJECT {
#   public this () {
#     prop = new FObject;
#   }
#
#   protected FObject prop;
# }

-- Chris Nicholson-Sauls