Re: Swarms and subSwarms: (was Re: Defininng and using an object as a Swarm and a SwarmObject at the sametime.

[William S. Shu]

>"William S. Shu" wrote:
>>
>> Please help me find practical ways of expressing the following conceptual
>> problem in Swarm (and adhere to Objective C requirements as well)
>> exemplified by:
>>
>> @interface MalariaPop:Population:SwarmObject
>
>> @interface MalariaPop:Population:Swarm
>
>>
>> MalariaPop is a population of malaria germs, and hence it is a kind of
>> population.  Inside a person, I am interested in the malaria population
as
>> an object, and so I define it as a swarmObject.  But MalariaPop contains
>> malaria germs, whose interactions I may also want to consider.  So I
define
>> MalariaPop as a Swarm!
>>
>I think the approach to William's problem should be as follows.
>
>Make the "highest level container" of Swarms at the model swarm level.
>So ModelSwarm is a Swarm.  The ModelSwarm does not create the micro
>level objects, rather it can create new "holding companies", little
>model swarms, in each of which you have these germs doing their
>business.  ...

    The discussion has helped clarify a few things.  I think this approach
by Paul fits better with what I would like to do.  But the multiple
inheritance issue does not quite go away, for the "holding companies" will
not inherit SwarmObject properties (which would ease eventual
modifications).  However, I wonder could happen if I use the Protocol
mechanism (as suggested by Alex) to tag on [a "side"] inheritance properties
of swarm objects to a swarm:
        @interface MalariaPop:Swarm <SwarmObject>
        {
         ...
        }
         ...
        @end

With the above could there be runt-time surprises?  Is there a possibility
of [internal/kernel] conflicts in the Swarm and SwarmObject when, say, their
methods are invoked?  (I do not hope to access SwarmObject class details,
except its protocols do so!)

A special problem case comes to mind.  Suppose a malariaPop object is a
Swarm that adheres to the SwarmObject protocol as given above.  If, seen as
a SwarmObject, it is dropped (destroyed), what should I (the programmer) do
to ensure that malariaPop, seen as a Swarm does not crash the system (e.g.,
via Seg. violation)?

Should I try to use the method:
        - (ref_t)addRef: (notify_t)notifyFunction withArgument: (void *)arg;
in the above scenario, how would I do it?  Which object, etc., should be
informed that malariaPop is no more?  Once informed, how does it ensure that
malariaPop is gracefully(?) removed from any/all schedules/swarm activities?

An Aside Question: Does one have to go through header files to find the
definitions of ref_t and notify_t?  More specifically, how does one get at
the definition of non-basic types (such as ref_t and notify_t above)
associated with the declaration of swarm-related methods/values.


>
> My question would be: why do it?
>
In response to the above question by Joseph,  the need for multiple
inheritance arises because I must allow for the malaria germs to be viewed
from macroscopic and microscopic viewpoints under yet-to-be-determined
constraints.  They may also be in different environments (persons,
mosquitoes, culture solutions, ...) and may migrate among them, as suits the
investigator (who probably does not know much about computers).

William.



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