www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Interdependent modules?

reply Jeremy Gibson <jtgibson telus net> <Jeremy_member pathlink.com> writes:
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
Jun 19 2006
next sibling parent reply Carlos Santander <csantander619 gmail.com> writes:
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
Jun 19 2006
parent reply kris <foo bar.com> writes:
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 :)
Jun 19 2006
next sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
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
Jun 19 2006
parent reply Jeremy Gibson <jtgibson telus net> <Jeremy_member pathlink.com> writes:
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.
Jun 19 2006
parent Derek Parnell <derek nomail.afraid.org> writes:
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
Jun 19 2006
prev sibling parent Jeremy Gibson <jtgibson telus net> <Jeremy_member pathlink.com> writes:
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...
Jun 19 2006
prev sibling parent reply BCS <BCS pathlink.com> writes:
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)
 




  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.
Jun 20 2006
parent Jeremy Gibson <jtgibson telus net> <Jeremy_member pathlink.com> writes:
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. =)
Jun 20 2006