jpd00964@uxa.cso.uiuc.edu (10/19/89)
Can someone tell me the point behind posing in Objective C? I have read the Cox book and StepStone manual, but they seem to be missing what posing is used for. Thanx Michael Rutman Softmed
jacob@gore.com (Jacob Gore) (10/20/89)
/ comp.object / jpd00964@uxa.cso.uiuc.edu / Oct 19, 1989 /
Can someone tell me the point behind posing in Objective C?
----------
A major point in Brad Cox's "Software-IC" (tm Stepstone) concept is that
they can be distributed in binary libraries, with no accompanying sources.
(Since version 4.0 of Stepstone's compiler, it also makes very good sense
to distribute the .h files ("include-files") containing the interface
definitions for the classes.)
Posing allows you to make orthogonal changes to a class for which you have
no source code, even if it is not a leaf in the inheritance tree.
For example, you may want to add a property to all objects, but you have no
source code for Object. You can then write a class, say, BetterObject
which inherits from Object, and in its +initialize method ("+" in
Objective-C signifies a class method) issue
[self poseAs:[Object class]]
Then, all members of Object and its subclasses will gain the new properties
that you added through BetterObject. Of course, you have to be very, very
careful not to break any assumptions any of the other code makes about
Object. Also, you need to make sure that BetterObject is capable of
unarchiving an Object (if you use the archival facility).
Posing can also be used, in a jam, to try to get around the lack of
multiple inheritance. I'm very much opposed to this use, but one can't
always help it. For example, you have a classes F, J, L, Q, T, U and Z,
scattered through your inheritance tree, which all need properties from a
new class M (a nontrivial amount of code), which is not in the tree yet.
If you had multiple inheritance, you could add M to the list of
superclasses of F, J, L, Q, T, U and Z. But without multiple inheritance,
you either have to add copies of M's code to each of these classes, which
doesn't improve your maintenance prospects much, or find the closest common
ancestor of all these classes, say, B, and add M's code to it (asuming, of
course, that the code is orthogonal to what is already there and doesn't
break anything...). If you don't have the source to B, you can make M a
subclass of B and make it pose as B. Sickening, isn't it...
I had to use +poseAs: once for a very practical reason. I had to write a
rather general class, which would be used in a program in a very
space-constrained environment. If the whole class was linked in, its code
would use up almost half of the total available space, so I had to break it
up into small... uhm, classlets (call them C1,...,Cn). But the requirement
was to make any combination of these classlets look like one class (C) to
the programmer-customer (the person who links with it -- it was to be a
binary library distribution).
If multiple inheritance was available, I'd just let the programmer-customer
define class C as a subclass of whatever combination of C1,...,Cn. Not
having multiple inheritance, I used +poseAs:. C was a class that declared
the instance variables and only those methods that always had to be linked
in anyway (like +new). C1,...,Cn were direct subclasses of C, and each
would pose as C. The programmer-customer selected the classlets through a
pseudo-link-time command which I don't think applies to Objective-C 4.0.
This worked because +poseAs: is transitive. Suppose I specified to link in
C1, C3 and C5. Here's what the piece of the inheritance tree looks like
at first:
C -> original C
after [C1 poseAs:[C class]] it becomes:
original C
|subclass
C -> C1
after [C2 poseAs:[C class]] it becomes:
original C
|subclass
C1
|subclass
C -> C3
and, finally, after [C2 poseAs:[C class]] it becomes:
original C
|subclass
C1
|subclass
C3
|subclass
C -> C5
So, the messages that what is now known as C recognizes is the union of
those recognized by the original C, C1, C3 and C5.
Jacob
--
Jacob Gore Jacob@Gore.Com boulder!gore!jacob