Re: BUG #1589: The whole concept of forces/move_with_forces/forces_holder needs to be rethought

[Ingo Ruhnke]

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).

> However, there is one advantage that Function Objects have.  It is 
> possible for an action use multiple collision functions using Function 
> objects.

Yep,

> I suppose you could also use the second example to do this. You
> won't be able to do this with the first example.

Of course one can apply any number of workarounds to get the same
behaviour with both methods, but function objects are simply far more
powerfull.
 
> 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.

-- 
WWW:      http://pingus.seul.org/~grumbel/ 
Games:    http://pingus.seul.org/~grumbel/gamedesigns/
JabberID: address@hidden 
ICQ:      59461927