Re: static or dynamic, that is the question.

[glen e. p. ropella]

At 07:45 PM 10/26/99 -0400, you wrote:
> I am interested in creating a model in which agents are members of
> different subclasses of the same abstract class.  What should I consider
> with regard to  static/vs dynamic typing when the agents interact?
>
> I want to be able to sent the same kind of message to all agents, but I
> want agents to do different things depending on which subclass they belong
> to.
>
> In general, I'd be interested in any relevant references and/or code
> samples, as well as any information about design issues that one might
> consider in order to best take advantage of Objective C's runtime system.

Hey Matt,
Here's an example of ... ahem... interesting typing that
I used when I threw together my last model.  Don't take this as
*the* way to do anything; but, it could be useful.

Here's part of my hierarchy:
SysDynObject:
  Operation
  Reservoir:
    Source
    Sink

Here's the interesting part of the interface for SysDynObject:
--------
@interface SysDynObject: DiGraphNode {
[...snipped...]
}
[...snipped...]
- (id <Warning>) addOutControlTo: (SysDynObject *) op
                          ofType: (const char *) aType; // op only
[...snipped...]
@end
---------

The "op only" comment indicates that "controls" only go to
Operations, not Reservoirs.  So, in the implementation of
SysDynObject, we have:
----------
- (id <Warning>) addOutControlTo: (SysDynObject *) op
                          ofType: (const char *) aType {
  Control *c;
  if (op == nil)
    raiseEvent(WarningMessage, "Can't send Control (%s) to Sink.",
               [self getType]);
  c = [Control create: [self getZone] canvas: canvas
                             from: self to: op ofType: aType];
  [outControls add: c];
  [[(Operation *)op getInControls] add: c];
  return nil;
}
----------

Note that the argument (op) is typed to the superclass
but cast to Operation before it's used.  Now, the method
getInControls, is declared and defined in Operation.[hm],
which means that if (op) actually is a Reservoir and not
an Operation, then at run-time, the system will
stop and say that Reservoir doesn't respond to "getInControls".

OK.  Now, there are alternate gymnastics one can go through
to provide this kind of info at compile time.  For
example, rather than declaring the "addOutControlTo" as:
---------
- (id <Warning>) addOutControlTo: (SysDynObject *) op
                          ofType: (const char *) aType {
---------
we could use:
---------
- (id <Warning>) addOutControlTo: (Operation *) op
                          ofType: (const char *) aType {
---------

But, if we do that, then we have to do a cyclic #import
and include the Operation.h file into its superclass'
header (rather than its implementation), which, to me,
is uglier than casting.

So, while this probably isn't that helpful for you,
it does give a hint as to how typing *could* (not *should*)
be used.  And, in fact, I'm not really using the typing
for anything other than readability because the run-time
still goes through the test to see if (op) accepts the
message or not, which it would do even if I cast (op) to
(id) instead of (Operation *).

As Marcus pointed out, going through a little extra work
and putting in protocols for things like this is the
way it *should* be done (if moral imperatives have any
place in programming).

glen

--
glen e. p. ropella =><= Feeding the hamster wheel.  Hail Eris!
Home: http://www.trail.com/~gepr                (505) 424-0448
Work: http://www.swarm.com                      (505) 995-0818

                 ==================================
  Swarm-Support is for discussion of the technical details of the day
  to day usage of Swarm.  For list administration needs (esp.
  [un]subscribing), please send a message to <address@hidden>
  with "help" in the body of the message.