www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Modules named "object" with DMD 0.153

reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
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
Apr 11 2006
parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
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.
Apr 11 2006
next sibling parent reply AgentOrange <AgentOrange_member pathlink.com> writes:
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
Apr 12 2006
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
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
Apr 12 2006
prev sibling parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
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
Apr 12 2006