I have a pair of modules which need one another's functionality, and I've been poring through the documentation on trying to figure out how to get them working together, to no avail.  The structure is basically as follows (with unnecessary baggage trimmed out):

gameobject.d
============
import data (for ac_data class)
class ac_object : ac_data

data.d:
=======
import gameobject (for ac_object class)
class ac_data
class ac_location : ac_data
class ac_region : ac_location
function ac_region.Contains(ac_location location)
function ac_region.Contains(ac_object object)


Naturally, the compiler doesn't like this kind of cross-dependency of modules. However, being a total newbie doesn't help me find an answer, so I thought I'd resort to the experts.

How can I define a Contains() function override for the ac_region class that accepts an ac_object as a parameter?  Is it possible to get the ac_region.Contains() function to safely operate on an ac_object (which is deliberately defined in a different module) without having to remove the function from data.d?

I'd prefer not to define the ac_region functionality in a seperate module because it should be a part of the standard suite of data types conferred by the "data" module.  I always could define it seperately if absolutely necessary, though I'd secretly hate myself... =P

Jeremy Gibson <jtgibson telus net> escribió:
> I have a pair of modules which need one another's functionality, and I've been
> poring through the documentation on trying to figure out how to get them working
> together, to no avail.  The structure is basically as follows (with unnecessary
> baggage trimmed out):
> 
> gameobject.d
> ============
> import data (for ac_data class)
> class ac_object : ac_data
> 
> data.d:
> =======
> import gameobject (for ac_object class)
> class ac_data
> class ac_location : ac_data
> class ac_region : ac_location
> function ac_region.Contains(ac_location location)
> function ac_region.Contains(ac_object object)
> 
> 
> Naturally, the compiler doesn't like this kind of cross-dependency of modules.
> However, being a total newbie doesn't help me find an answer, so I thought I'd
> resort to the experts.
> 

The only reason why the compiler shouldn't accept it is if you have module ctors or static class ctors in both modules. You should try to remove them from one of the modules.

> How can I define a Contains() function override for the ac_region class that
> accepts an ac_object as a parameter?  Is it possible to get the
> ac_region.Contains() function to safely operate on an ac_object (which is
> deliberately defined in a different module) without having to remove the
> function from data.d?
> 
> I'd prefer not to define the ac_region functionality in a seperate module
> because it should be a part of the standard suite of data types conferred by the
> "data" module.  I always could define it seperately if absolutely necessary,
> though I'd secretly hate myself... =P
> 
> 

Before reading this I was going to say just that: put ac_data in another file, but if you can't, you can't :D

-- 
Carlos Santander Bernal

Carlos Santander wrote:
> Jeremy Gibson <jtgibson telus net> escribió:
>> Naturally, the compiler doesn't like this kind of cross-dependency of modules.
>> However, being a total newbie doesn't help me find an answer, so I thought I'd
>> resort to the experts.
>>
> 
> The only reason why the compiler shouldn't accept it is if you have module ctors or static class ctors in both modules. You should try to remove them from one of the modules.

Note that the -cov option will generate static-ctors, so you have to be aware of that with respect to cyclical imports :)

On Mon, 19 Jun 2006 21:12:10 -0700, kris wrote:

> Carlos Santander wrote:
>> Jeremy Gibson <jtgibson telus net> escribió:
>>> Naturally, the compiler doesn't like this kind of cross-dependency of
>>> modules.
>>> However, being a total newbie doesn't help me find an answer, so I
>>> thought I'd
>>> resort to the experts.
>>>
>> 
>> The only reason why the compiler shouldn't accept it is if you have module ctors or static class ctors in both modules. You should try to remove them from one of the modules.
> 
> Note that the -cov option will generate static-ctors, so you have to be aware of that with respect to cyclical imports :)

Just throwing out an idea here, but if two modules are dependant on each other, why not combine them into a single module?

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
20/06/2006 3:20:09 PM

>Note that the -cov option will generate static-ctors, so you have to be aware of that with respect to cyclical imports :)

AHA!  Yep, that'd do it.  I'm still in the scratch-build stage so I've been compiling with the code coverage enabled in order to ensure that the basic architecture is being called.  (Only after the basic architecture is implemented do I implement the actual functionality and content.  I'll probably rebuild half of it from scratch before I'm done, but damn does it ever feel right to do it this way. ;-))

I suppose with an adequate testing suite I don't really need the code coverage, since there's a huge number of functions that're going to be unexecuted now anyway...

>Just throwing out an idea here, but if two modules are dependant on each other, why not combine them into a single module?

Two reasons, although I'll admit that I hadn't thought of that. ;-)

First and foremost is length: my object class are heavyweight classes which represent objects existing in 3D; my data classes are lightweight classes for storing simple information (they'd be justifiable as structs, really).  Second is specialisation: the data classes are very, very simple and generally applicable, but the object classes are the root of a whole hierarchy of classes, and have (rather, will have) a lot of physics and the like that isn't really relevant to most other modules.

I suppose the easiest way to describe the difference is by saying that objects are of actual interest to the end user of the program, while the data classes are only of use to the programmer: I'd prefer to keep those different concepts distinct to make things a little more manageable on my end.

On Tue, 20 Jun 2006 06:29:38 +0000 (UTC), Jeremy Gibson wrote:

>>Just throwing out an idea here, but if two modules are dependant on each other, why not combine them into a single module?
> 
> Two reasons, although I'll admit that I hadn't thought of that. ;-)
> 
> First and foremost is length: my object class are heavyweight classes which represent objects existing in 3D; my data classes are lightweight classes for storing simple information (they'd be justifiable as structs, really).  Second is specialisation: the data classes are very, very simple and generally applicable, but the object classes are the root of a whole hierarchy of classes, and have (rather, will have) a lot of physics and the like that isn't really relevant to most other modules.
> 
> I suppose the easiest way to describe the difference is by saying that objects are of actual interest to the end user of the program, while the data classes are only of use to the programmer: I'd prefer to keep those different concepts distinct to make things a little more manageable on my end.

In that case, it sounds like even further refactoring is required to isolate those things that are only dependant on the module that contains them.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
20/06/2006 4:53:37 PM

Jeremy Gibson <jtgibson telus net> wrote:
> I have a pair of modules which need one another's functionality, and I've been
> poring through the documentation on trying to figure out how to get them working
> together, to no avail.  The structure is basically as follows (with unnecessary
> baggage trimmed out):
> 
> gameobject.d
> ============
> import data (for ac_data class)
> class ac_object : ac_data
> 
> data.d:
> =======
> import gameobject (for ac_object class)
> class ac_data
> class ac_location : ac_data
> class ac_region : ac_location
> function ac_region.Contains(ac_location location)
> function ac_region.Contains(ac_object object)
> 

option #3

 gameobject.d
 ============
 import data (for ac_data class)
 class ac_object : ac_data

 data.d:
 =======
// import gameobject (for ac_object class)
 class ac_data
 class ac_location : ac_data
// class ac_region : ac_location
// function ac_region.Contains(ac_location location)
// function ac_region.Contains(ac_object object)


 geometry.d:
 =======
 import data (for ac_location class)
 import gameobject (for ac_object class)

 class ac_region : ac_location
{
 function ac_region.Contains(ac_location location)
 function ac_region.Contains(ac_object object)
}

Might work.

In article <e7966s$1ds7$6@digitaldaemon.com>, BCS says...
>
>[snip - separating region class into another module]
>
>Might work.

That was one of the solutions I had considered, but because locations and regions are basic, necessary constructs in just about every module, I didn't want to resort to it -- I'd have to remember to import two modules in any module that used both.

I disabled code coverage, per kris' suggestion, and I still couldn't compile the project.  The solution I ultimately resorted to was to reverse the logic of the ac_region.Contains(ac_object object) function, such that I use an ac_object.InRegion(ac_region region) function.  This removes interdependency and also allows me to keep code coverage on. =)