Re: subclassing again

[Roger M. Burkhart]

> I thought my problem was solved. It is not. If I try to compile the whole
> library which I defined I run again into problems. No I located in detail
> what happens. If you import swarmobject.h you import OrderedSet.h via the
> sequence
> 
> swarmobject.h
> Swarm.h
> GenericSwarm.h
> ActionGroup.h
> OrderedSet.h
> 
> OrderedSet.h imports collections/List_mlinks.h. And here MLINKS is set to 1!

Great, you found the problem!  The thing about the grid programs is that
they import only the most basic libraries without importing the packaged
swarmobject context, and that's why I didn't see the problem in those
examples.

> How can I circumvent this problem? I must somehow control the sequence how
> things are imported. I am not sure how to proceed.

Import dependencies are still something requires some trial-and-error
tweaking to get worked out right in Objective C, and even then there can
be some hard cases to cover.  Your use of inheritance exposed more
conflicts than we had seen before or knew were there.  We need to make
sure that header files from libraries avoid all conflicts that could arise
from legitimate use, and your subclassing should be a case of that.

To avoid header conflicts our basic policy is to be as conservative as
possible in *not* importing anything into a public header file that isn't
strictly required by the file itself.  In GenericSwarm.h we violated this
rule with some baggage left behind from its history.

To fix the problem, just delete the line:

#import <activity/ActionGroup.h>

from GenericSwarm.h.  That's that line that brought in the conflicting
OrderedSet.  That line will be gone in the next release of the library,
but it's not needed for compiling even now.  Just remake the activity
library after you delete the line.

Thanks for chasing this down.  In retrospect I should have tested a little
further with the full import context we provide through swarmobject, but
this case will help point out the kind of problems that can arise from the
class selection techniques I use in some of the basic libraries.

Let me know if subclassing still has any problems with the import context
fixed.  We still need to work out more general support for subclassing
from the internal implementation classes.  Is your reason for wanting to
subclass mainly just to avoid the overhead of coding your own methods that
pass through selected calls to a collection contained as an instance
variable?

Roger