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

[Gervase Lam]

Read about function objects in STL this past weekend and have also been 
thinking about how moving/colliding could be implemented.

The problem with function objects is that it deviates away from the object 
orientation idea of implementation and data being in one object.  That is, 
a function object is a separate entity from PinguAction and classes 
derived from it.

> From: David Philippi <address@hidden>
> Subject: Re: BUG #1589: The whole concept of
> forces/move_with_forces/forces_holder needs to be rethought
> Date: Wed, 6 Nov 2002 13:51:13 +0100

> > But why not use this basic idea rather than member templates?
>
> Because you would either have to include the same collision code in
> diffe= rent=20
> actions or you would have to derive the actions from=20
> PinguActionCollidingByMethodX
> where X is the right base class for the current action. The first
> would=20 introduce redundant code and the second creates an ugly class
> hierarchie.

One thing I thought of last night uses a couple of techniques adapted from 
Effective C++ by Scott Meyers that could solve this problem.  You could do 
something similar to this:

/** First, the base class **/
class PinguAction
{
protected:
  bool default_collision_at(int a, int b);
  bool collision_at1(int a, int b);

public:
  void move_to();

  /*
  = 0 stops this from being unintentionally used as a default method.
  This was the idea that Effective C++ was really talking about.
  */
  virtual bool collision_at(int a, int b) = 0;
}

bool PinguAction::default_collision_at(int a, int b)
{
// "Default" collision function
}

bool PinguAction::collision_at1(int a, int b)
{
// A different collision function
}

/** Now some derived classes **/
class Action1 : public PinguAction
{
public:
  virtual bool collision_at(int a, int b)
    { return default_check_collision(a, b); };
}

class Action2 : public PinguAction
{
public:
  virtual bool collision_at(int a, int b)
    { return default_collision_at(a, b); };
}

class Action3 : public PinguAction
{
public:
  virtual bool collision_at(int a, int b)
    { return collision_at1(a, b); };
}

class Action4 : public PinguAction
{
public:
  virtual bool collision_at(int a, int b)
    { return collision_at1(a, b); };
}

Effective C++ gives another example that does not use a separate function 
in order to provide default implementation.  The below really needs 
tidying up.  However, it is just for ideas:

/** First, the base class **/
class PinguAction
{
public:
  void move_to();
  virtual bool collision_at(int a, int b) = 0;
  virtual bool collision_at1(int a, int b) = 0;
}

bool PinguAction::collision_at(int a, int b)
{
// "Default" collision function
}

bool PinguAction::collision_at1(int a, int b)
{
// A different collision function
}

/** Now some derived classes **/
class Action1 : public PinguAction
{
public:
  virtual bool collision_at(int a, int b)
    { return PinguAction::collision_at(a, b); };
}

class Action2 : public PinguAction
{
public:
  virtual bool collision_at(int a, int b)
    { return PinguAction::collision_at(a, b); };
}

class Action3 : public PinguAction
{
public:
  virtual bool collision_at(int a, int b)
    { return PinguAction::collision_at1(a, b); };
}

class Action4 : public PinguAction
{
public:
  virtual bool collision_at(int a, int b)
    { return PinguAction::collision_at1(a, b); };
}

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

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

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?

Thanks,
Gervase.