Description Miles Parker 2011-04-26 00:52:58 EDT

Using the latest drop, I launched a runtime environment and imported the example models. Two of the example models had errors for the models themselves, Demographic.. and Markets. Most of the other models had errors like the below:

Description	Resource	Path	Location	Type
heatCellProto cannot be resolved	Heatbugs.java	/org.eclipse.amp.amf.examples.escape/srcgen/org/eclipse/amp/examples/heatbugs	line 384	Java Problem

Of course, this is just more incentive to fix the code generation testing infrastructure.

In terms of the changes themselves, we should talk about the generated code. I'd neglected to give good feedback and ideas before do perhaps this would be a good thread to discuss various overall unstated design goals/guidelines for the host environment. I've been up till know holding these in my own head so there is no way that they would have been know to anyone else. :)

1. We should avoid at almost all costs explicit dependencies on amp/escape API for the generated model. (e.g. org.eclipse.amp.escape.runtime.extension.IAgentChild). I know this is a bit counter-intuitive, but the reason is that Escape has a mandate to be an exemplar of an ABM target without any such dependencies and more practically, we want Escape and Ascape code to be able to co-exist without significant porting changes required between environments. Now, an objection is that we actually do have SWT and AMP (but *not* Escape, except for a couple of special cases) dependencies in the model, but those are all view dependencies without which we could not of course run the environment within Eclipse.

2. Going along with this, even though they are far from perfect, we should follow the overall Ascape "way of doing things" for the generated code. In other words, generated code should be ideally indistinguishable from hand-written code and we should have to resort to much code generation magic to accomplish high-level functionality. Instead, we should look to the Ascape patterns and adopt them. For:

	public void executeOnMembers() {
		int timeStep = getRunner().getPeriod();
		startSimulationAgentChild(timeStep);

		((HeatBug) heatBugScape.getPrototypeAgent())
				.startSimulationAgentChild(timeStep);

		((HeatCell) heatCellScape.getPrototypeAgent())
				.startSimulationAgentChild(timeStep);

		super.executeOnMembers();
		calculateTimeStep(timeStep);

		((HeatBug) heatBugScape.getPrototypeAgent())
				.calculateTimeStep(timeStep);

		((HeatCell) heatCellScape.getPrototypeAgent())
				.calculateTimeStep(timeStep);

	}

	/**
	 * <!-- begin-user-doc -->
	 * 
	 * <!-- end-user-doc -->
	 * @generated
	 */

	public void startSimulationAgentChild(int timeStep) {
		if (timeStep == getRoot().getRunner().getEarliestPeriod()) {
			for (IAgentChild tmp : children) {
				tmp.startSimulation(timeStep);
			}
		}
	}

Let's talk about what we're trying to accomplish here and how we could do it within Ascape paradigm. I realize that this adds an additional perhaps unwelcome constraint but I believe these are important design objectives.

Now, in the bigger picture, I am not saying that it is inappropriate to generate code that makes use of what we can infer from the meta-model. We should be looking to do exactly that as it will support a very open ended environment without legacy entanglements from Ascape and a much lighter weight API. But that's I think more of a new effort. I hope this makes sense.