Types -- was (Re: [Repast-developer] Evolutionaries and Revolutionaries)

[Mark R. D. <mdi...@la...>]

Mark R. Diggory wrote:
> 
> Tom Howe wrote:
>> First off, we should just get rid of space2.  It was a
>> brief playground I was using.  

> I've been working your demo model package, replacing space2 with space 
> in it to see how well my changes work with your current strategy. It 
> almost works, accept for some of the "Type" issues I pointed out to in 
> my last email.

This issue is is something I'm struggling with at the moment. Maybe we 
should discuss the policy for defining "types" or "labels" for this 
particular subject.

1.) In some situations we'd really like to use things like

	context.getRelation(object, object, SomeTopology.type);

to have this capability requires that all Toppologies be separate 
classes and a Context can never contain two RelationalTopologies of the 
same class.

2.) If in some situations we may want to define two Topologies that are 
of the same class, then some other mechanism needs to be used:

RelationTopology.getRelationType();

and

RelationTopology.setRelationType("foo");

accomplish this task, but are fraught with risk of altering the 
Topologies type from that of the key its actually stored under in the 
Context mapping.

3.) I proposed that we possibly remove the setTopologyType from the 
interface and force all implementations to accept String arguments of 
assigning type in the constructors.

private String type;

public FooTopology(String type, ...){
    this.type = type;
}

public String getRelationType(){
    return type;
}

...

By this means types become more immutable over the lifetime of the object.

4.) The problem is that FooTopology.type is a simplified means of 
getting at the lookup key for a specific Topology in the Context. The 
ease of being able to do a static "SomeTopology.type" is nice. We still 
do not get this kind of capability. It is a "shot in the foot" to not 
have this kind of capability in "types" because otherwise you need to 
either keep track of the keys and know which your working with, or you 
need to keep track of the objects to know which one to get the 
"getRelationType()" content from to look it up in the Context.

As such I do not know what the best solution here at this point is. Do 
we want it to be the case that when a model writer is building a model 
that they extend all the classes to create a different Topology class 
for each Topology they want to map?

public class FooTopology extends Object2DGrid {
    public static final String type = "foo";
    ...
}

public class BarTopology extends Object2DGrid {
    public static final String type = "bar";
}

I'm not sure I like this idea either.


-Mark