[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Apr 1 11:41:18 1996 
Subject:mixins or sub-objects? 
From:Aaron Sloman 
Volume-ID:960401.01 

I am extending the Pop-11 sim_agent library with some default techniques
for graphical tracing of moving objects/agents based on the rc_graphic
library.

The key idea is to have the notion of a graphical object defined by a
location, and some specifications of strings and line-segments whose
coordinates are given relative to the location. Thus the object is
easily redrawn after the location is changed.

Information about the sim_agent library (based on Objectclass and
Poprulebase) is available via the Birmingham Poplog ftp site

    ftp://ftp.cs.bham.ac.uk/pub/dist/poplog

or the Cognition and Affect project directory
    ftp://ftp.cs.bham.ac.uk/pub/groups/cog_affect
    http://www.cs.bham.ac.uk/~axs/cog_affect

I am undecided between the two following ways of making the graphical
facilities available to users of the library, within the context of
Objectclass.

-- Strategy 1: use a graphical object mixin -----------------------------

This would define one or more mixins which add the appropriate extra
slots for a graphical objects and movable objects, e.g. something like
this.

define :mixin rc_linepic;
    ;;; Information needed for a (static or mobile) drawable object
	;;; coordinates of point relative to which to draw
	slot rc_startx;
	slot rc_starty;
	;;; A list of line-pictures to draw.
	slot rc_pic_lines = [];
	;;; A list of strings to draw.
	slot rc_pic_strings = [];
enddefine;

define :mixin rc_linepic_movable; is rc_linepic;
	;;; Extend the mixin to include a record of previous location
    ;;; used for drawing moving objects.
	slot rc_oldx = false;
	slot rc_oldy = false;
enddefine;

Then objects with graphical counterparts could use these mixins
and their associated methods.


-- Strategy 2: use use separate object classes and slots for them -------

Instead of making the above mixins I could call them classes.
Then any drawable class could have a slot for the associated
"picture"

    sim_picture = instance rc_linepic_movable; ..... endinstance;

In that case drawing the object would involve accessing the sim_picture
component and applying the drawing methods to that. Similarly whenever
the object's location changed, the location slots for the sim_picture
would also have to be changed.


Does anyone have comments on the relative merits of these?

Without knowing how objectclass is implemented, my instinct tells me
that for a class of objects which is only rarely drawn or re-drawn the
second strategy, though slightly less convenient, is bound to be
significantly more efficient than the former method because use of the
non-graphical slots or methods will normallyh require searching further
up the class hierarchy. Alternatively it may be possible to insert
the graphical mixin sufficiently near the top of the hierarchy
for most relevant slots and methods to be defined lower down.

Does anyone have any comments on this? I presume there are similar
issues in relation to CLOS, so I'll post this to both comp.lang.pop and
comp.lang.clos

Aaron
-- 
Aaron Sloman, ( http://www.cs.bham.ac.uk/~axs )
School of Computer Science, The University of Birmingham, B15 2TT, England
EMAIL   A.Sloman@cs.bham.ac.uk
Phone: +44-121-414-4775 (Sec 3711)       Fax:   +44-121-414-4281