Re: Collider and Mover code

[Gervase Lam]

> Date: Fri, 17 Jan 2003 19:11:53 +0100
> From: David Philippi <address@hidden>
> Subject: Re: Collider and Mover code

> > In any case, I think pingu_collider needs to be changed to just
> > collider.
> > This is because the abstract class pingu_collider should apply to any
> > object, not just Pingus.
>
> What other objects do you think should collide with each other? Defining
> = the=20
> scope of the class is required to answer your next questions.
>
> > But does this mean that collider should not have a getpixel() method?
> > Does getpixel() apply to all other objects?  Should the class
> > hierarchy be
> > collider<-pingu_collider<-upright_pingu_collider or
> > collider<-upright_pingu_collider?

May be I should have asked a better question here.  If getpixel() were 
moved to collider and pingu_collider added, pingu_collider would be a 
class that would add no functionality.  It would only add a possibly more 
future proof hierarchy?

For example, something in the future could be added to pingu_collider 
because it is something in common with all pingu_colliders.  Having 
pingu_collider would (could!?) make this easy.

Also, if the former class hierarchy were to be adopted, does this mean 
that there should be a directory structure like 
"Games/Pingus/src/colliders/pingu_colliders"?

With regards to the hierarchy question you asked, I'll quote from what 
Ingo wrote last year.

> Subject: Re: BUG #1589: The whole concept of
> forces/move_with_forces/forces_holder needs to be rethought From: Ingo
> Ruhnke <address@hidden>
> Date: 28 Nov 2002 19:57:42 +0100

>
> Gervase Lam <address@hidden> writes:
> > The problem with function objects is that it deviates away from the
> > object orientation idea of implementation and data being in one
> > object.
>
> PinguAction itself already 'deviates away' from that in much the same
> way as the collide stuff.
>
> > That is, a function object is a separate entity from PinguAction and
> > classes derived from it.
>
>  
> Yep, and thats good for a number of reasons, keeping everything in the
> same objects just leads to a whole bunch of inter-dependencies and non
> reusable pieces of code. Keeping the collision stuff seperate will
> result in something that is reusable in a number of situations (for
> example some worldobjects might use it).

> > Also, how should things be set up if Function Objects were used? I
> > suppose the function objects would be in two files called
> > collision_at.hxx and collision_at.cxx in the source root directory?
>
> Something like that. Beside the collision stuff we should also keep
> track of a generic terrain-traversal engine, currently its all in
> walker and duplicated more or less in climber and sooner or later in
> the slider. But keep in mind that all code changes need to make the
> situation better and not worse, breaking actions is just too easy.

-- 

Thanks,
Gervase.