jon@runxtsa.runx.oz.au (Jonathon Seymour) (10/04/89)
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.