Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!munnari.oz.au!csc!ccadfa!usage!basser!metro!ipso!runxtsa!jon
From: jon@runxtsa.runx.oz.au (Jonathon Seymour)
Newsgroups: comp.lang.c++
Subject: Information 'of' and 'about' objects: a discussion
Keywords: objects techniques
Message-ID: <299@runxtsa.runx.oz.au>
Date: 4 Oct 89 14:33:33 GMT
Reply-To: jon@runxtsa.runx.oz.au (Jonathon Seymour)
Organization: RUNX Unix Timeshare.  Sydney, Australia.
Lines: 92

I have asked this question once before but no-one in the aus distribution
was interested. So, world, here it is! 

Has there been any research into object oriented language facilities which
recognises the distinction between the information 'of' and the information
'about' an object?

I use the word 'about' in much the same way that it is used in relation to
mathematical theories. There are theories 'of' something, and then there are
theories 'about' theories. Information 'about' objects is significant only
to the user of the object, not to the implementor of the object.  

In my view the distinction is important because it has the potential to
simplify the design of class libraries. One quick example: A multi-user
graphics application running in a concurrent environment needs to associate
a user_id with every shape it manipulates. Shapes are passed to the
application, from the shape library, in an order determined by the
users - that is, randomly.

The user_id is an attribute of the shape from the point of view of the
application, but not from the point of view of the implementor of the shape
library - it is information 'about' the shape. 

So, where does the user_id go?

It can't go in the shape's base class or in a class derived from the shape's
base class, because the declaration of the shape library should be
independent of the particular requirements of any application that uses it. 

It can't go in a class which contains both the shape and the user_id because
the shape library manipulates shape pointers, not containers. The application
doesn't want to have to re-associate a container reference with the
shape pointer every time it gets a shape pointer from the shape library.

The best solution would appear to be to design the shape library so that
it manipulates generic shape containers - a class containing a shape 
plus a generic reference to auxiliary information. One way to do this
is to derive the shape class from a class, which I call a capsule class. 
This way all derivations from the shape class have the potential to hold 
references to auxiliary information. 

I have a penchant for generalisation so, instead of a single generic
reference to application specific information, the capsule class includes a
table of references (lookup). This way a number of independently developed
modules can 'share' an object of the capsule class. 

typedef unsigned key;

class capsule : public info {
protected:
	lookup	   table; // table of application specific info
public:
	info *select(key k)            { return table.select(k); };
	info *attach(key &k, info *i)  { return table.add(k, i); };
	capsule(unsigned size = 0) : table(size) {};
	~capsule(void);
};

The select method looks for an info object with matching key, k. The attach
method attaches an info object to the capsule with a key k, returning the
previous object attached to the capsule with that key. attach(k, (info *)0)
detaches an info object from a capsule. 

The info class, shown below, is a cludge necessary to implement the
capsule destructor. The capsule destructor causes info objects attached to a
capsule to be detached when the capsule is destroyed. Capsule is derived from
the info class to permit capsules to be attached to other capsules. 

class info {
public:
	key	id;	// key of this attachment
	capsule *c;	// capsule which this object is attached to
	
	virtual void attach(capsule *c); // attach info to new capsule
	virtual void detach(void);

	info(void) : id(0), c(0) {}; // .. for capsules
	info(capsule *c);	     // .. for attachments to capsules

	info(key &k, capsule *c);    // .. for attachments with their own key

	virtual ~info(void) { detach(); };
};
 
To limit the size of this already long article I won't show any detailed
examples of how capsules may be used. 

Any comments about this approach to structuring information 'about' objects?
Is the 'of'/'about' distinction recognised in languages other than C++?
Should it be? How? 

jon.