Re: Can a Swarm instance be treated like a SwarmObject instance?

[Ken Cline]

On Thu, 22 Apr 1999, Paul E. Johnson wrote:

> Ken Cline wrote:
> > 
> > I presume the `createBegin:' fragment below is from the
> > SmlSwarm.m.  If so, why are you assigning the pointer
> > returned from `[super createBegin: aZone]' (that is, 
> > `[Swarm createBegin: aZone]') to a SmlObject pointer?
> > 
> > (As I recall) By default the ivars for ObjC objects will
> > have a protected access level and hence the compiler is   
> > correct to warn you about trying to access SmlObject ivars
> > from a SmlSwarm method.
> 
> That createBegin language is in the TemplateModelSwarm.
> I imagine that is where it came from.    See Here:
> 
> +createBegin: (id) aZone { 
>   TemplateModelSwarm * obj;
>   id <ProbeMap> probeMap;
>   
>   obj = [super createBegin: aZone];
> ...........
>
> I've often wondered why it is done that way.

Why what is done what way?

> What would you think he should do instead in the case of
> his "nested" Swarm classes? 

Explain "nested". Are you refering to an inheritance or
composition relationship?

> I wonder if it ought to directly call the Swarm class in
> the SmlSwarm?  I mean include Swarm.h and then do [Swarm
> createBegin: aZone] ?

No.  Don't replace `[super createBegin: aZone]' with
`[Swarm createBegin: aZone]'.

Yes, it'll work in William's example, but if you change the
inheritance relationship (i.e. interface definition) then
you'll have to change `createBegin:'.  To put it bluntly,
that's poor programming. >:-(

I only used the word "Swarm" in place of the word "super" to
emphasize that the `createBegin:' message was being sent to
the Swarm class not to SmlObject.  Hence, one would expect
that the return result from `createBegin' would be assigned
to (a pointer to) a *subclass* of Swarm.  SmlObject does not
subclass Swarm, right?  So why would you have a SmlObject
pointer pointing at a Swarm?  (Am I missing something?)


On Thu, 22 Apr 1999, William S. Shu wrote:

> >From my understanding of createBegin: this is OK: a 'partially created'
> object that allows for instance variables of the current class is provided
> from its super.  You could then access it and make modifications
> (assignments).  the object becomes 'fully created' when a createEnd message
> is later executed (elsewhere).

Yes.  I agree.

I guess I didn't explain my point very well.  Here a
simplified example:

Suppose I have 2 classes:
    @interface MySuperClass {} @end
and
    @interface MySubClass : MySuperClass {} @end

Typically, the `createBegin:' method for MySubClass would
be:

    @implementation MySubClass
        +createBegin: aZone {
           MySubClass * obj;
           obj = [super createBegin: aZone];
           ...
        }
      ...

Now, it looked to me that what you had was:

    @implementation MySubClass
        +createBegin: aZone {
           SomeOtherClass * obj;
    //     ^^^^^^^^^^^^^^
           obj = [super createBegin: aZone];
           ...
        }
      ...

I just didn't understand why you were assigning the result
of `[super createBegin: aZone]' to `SomeOtherClass *'?


> What I basically want to do is to have a collection of model swarms
> (populations of objects) which could also be treated as objects in other
> swarms.  Fortunately or otherwise, the model swarms share properties with
> other types of objects (which are not model swarms).  These properties are
> ideally put in separate classes which can then be inherited.
> 
> Unfortunately, this calls for multiple inheritance -- as some objects are
> definitely of SwarmObject class, while others are are model swarms (of Swarm
> class).  To circumvent the issue of multiple inheritance (not allowed in
> Objective-C), I experimented with duplicating the code.  In doing this,
> other problems get raised ... and I seek for assistance from swarm-support!
> 
> BTW, trying to circumvent multiple inheritance by using protocols, like so:
>         @interface SmlSwarm: Swarm <SwarmObject>
>          {...}
>          ...
>         @end
> 
> causes compile-time screams that I have not fully implemented protocol
> interfaces, e.g:
>         ...
>        SmlSwarm.m:375: warning: method definition for `-_I_Using' not found
>        SmlSwarm.m:375: warning: class `SmlSwarm' does not fully implement
> the
>         `SwarmObject' protocol
>         ...
> 
> I wonder if there is a way of automatically adding such missing protocol
> implementations from swarm libraries.  If so, life would be easier!

There are ways other than inheritance to combine (or 
alternatively, modularize) the functionality of classes; 
ObjC, in this respect, is more capable (e.g. forwarding) 
than other single-inheritance languages.  Note: (from
what've read) forwarding is strictly a runtime mechanism and
hence you can't achieve compile-time protocol conformance
via forwarding.  (If you could, that would be really cool!)

BTW, unless it has been "fixed", the objective-C compiler
does not detect that a subclass implements some or all of a
protocol via inheritance.  For example, you could write a
class that implemented the List protocol without actually
specifying that it does.  You then define a subclass of your
list class and specify that it (i.e. the subclass) 
implements the List protocol.  The compiler would (or used
to) complain about this. 

Basically, this means that it'll warn about things that
won't be a problem at runtime. You can quiet those warning
with the compiler option or with wrapper methods, possibly.

In particular, if you want to quiet the "`-_I_Using' not
found" warning, you could use a touch of Swarm (pre-
processor) magic; add
   PHASE( Using ) //;
to your implementation (i.e. .m file).  You may also need to
put `USING' in your interface definition (i.e. .h file), but
I didn't seem to need that.

I hope that helps.

Ken.

_________________________________________________________
Ken Cline                             address@hidden
SAIC                                 VOICE (410) 571-0413
Annapolis, MD                          FAX (301) 261-8427











                  ==================================
   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.