Yes, that's what we intended. I just wasn't sure when it got it and want to make sure we follow up on it.
I can see your frustration very well. :) I also see that we're making progress on the testing, which is great. But of course even if we had perfect test coverage that wouldn't address higher level design issues.
But one thing I should point out is that the high-level design approach for Ascape is pretty well described, both in papers and documentation. See e.g.:
And in Javadoc (though some of this may be a bit out-of-date):
The semantics of rule execution and agent structural hierarchy in particular are well defined.
Now...I am *not* saying that this is the best way to do things, only that it is one way that has worked at least for the particular target domain. Now that we are bringing SD in to the picture we will want to modify that or even throw it out altogether, but I think that the Acape frame -- with Escape as a simple exemplar extension -- gives us a relatively simple place to start. In fact, I know that there are things that are wrong with Ascape API, for example Agents have to explicitly extend a subclass and it would be better if they could implement an interface.
So..the reason that the IAgentChild thing is hard for me to understand the need for is that Ascape already has support for Agent hierarchies, as does MetaABM/Acore. We also have semantics for starting a simulation and so on. So I think I just need help understanding why those existing mechanisms can't be reused. It feels like I'm missing some essential point here. I'll also take a look at the new example models ... perhaps that will make it clear.
But no matter what we do, we don't want want to break the existing Ascape API codegen. If we need to we can just break that apart further. But right now, Scape.xpt is used for both the Escape and Ascape targets so even if we decide that it makes sense to change Escape, we Probably want to keep Ascape backward compatible.
Another completely reasonable option is to just declare the existing codegen mature and being discussing an entirely fresh approach to all of this, using Eclipse idioms such as providers, etc.. I am completely open to that, and in fact that's what the ICompositionProvider and other features are designed to support.
The Ascape generated code now imports IAgentChild, requiring a dependency on the o.e.a namespace that didn't exist before.
Good news. :)