Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!wuarchive!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.lang.c++
Subject: Re: C++ Limitation
Keywords: C++
Message-ID: <72532@microsoft.UUCP>
Date: 23 May 91 19:51:57 GMT
References: <1991May14.155950.4336@infonode.ingr.com>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 109

In article <1991May14.155950.4336@infonode.ingr.com> allgood@greg.b17a.ingr.com writes:
>   I would like to have the capability of telling some object A, to send
>message M to an object B where M and B are not specifically known to A.
>For example, I would like to create a ScrollBar and tell it "Hey, when 
>you get scrolled to a new location, send a 'move_to' message to this
>instance of class View".  I can do this in C++ if the ScrollBar class knows
>about the View class, but I want to create a generic ScrollBar which
>can send messages to classes which will be defined later.  


You might want to consider an approach similar to the below.  The basic
idea is to define an abstract notion of the "Action" [or whatever you want
to call it] that needs to be taken to keep the Scrollbar happy in 
certain situations.  An "Action" being typically invoking some method
on some object -- BUT -- the concept of an "Action" doesn't have
to explicitly define an Action as being such.  The concept of an "Action"
doesn't have to be defined to be "anything."  Rather, we can wait till
later and specialize Actions to meet our particular needs.  In this
case we're simply saying an Action looks something like a function of
one int parameter:

	Action doSomething;

	....

	doSomething(-2);

A ScrollBar then just needs to take a couple Action& parameters to specify
what needs to be done in certain situations.   Later, one can specialize
Actions by derivation to specify the way those Actions are actually
performed.  In our case, sometime after ScrollBars are defined, we decide
we need ViewActions to be the action of invoking a particular View method
on a View object.  Fine, ViewActions are Actions, so now a ScrollBar is
able to take the Action of invoking a View method on a View object.  Even
though ScrollBars know nothing about View objects.

/**********************************/

#include <stdio.h>
#include <iostream.h>

class Action
{
public: 
	virtual void operator()(int) = 0;
};

class ScrollBar
{
   protected:
      int t;
      Action& moved_to;
      Action& moved;

   public:
      ScrollBar(int _t, Action& _moved_to, Action& _moved) 
      : t(_t), moved_to(_moved_to), moved(_moved) { }

      void move(int dt)
	{ t += dt;
	  moved(dt);
	}
      void move_to(int _t)
	{ t = _t;
	  moved_to(t);
	}
};

/**************************************************/

// now, at some later point in time you can choose ScrollBar Actions to be
// actions related to Views:

class View
{
   public:
      View() {}
      void moved(int dp)
	 {cout << "View moved by " << dp << endl;}
      void moved_to(int p)
	 {cout << "View moved to " << p << endl;}
};

typedef void (View::*pViewMethod)(int);
class ViewAction : public Action
{
	View* obj;
	pViewMethod method;
public:
	ViewAction(View* _obj, pViewMethod _method)
	: obj(_obj), method(_method) { }

	virtual void operator()(int parm) { (obj->*method)(parm); }
};

main()
{
   View v;

   ViewAction moved_action(&v, &View::moved);
   ViewAction moved_to_action(&v, &View::moved_to);

   ScrollBar sb(5, moved_to_action, moved_action);

   sb.move(-2);
   sb.move_to(10);

   return 0;
}