Make ERF implement Iterable<ProbEqkSource> and ProbEqkSource implement Iterable<ProbEqkRupture>

[Kevin Milner]

This is just an idea, so feel free to disagree/discuss below. Personally, I find the following code to be very long winded:

for (int sourceID=0; sourceID<erf.getNumSources(); sourceID++) {
	ProbEqkSource source = erf.getSource(sourceID);
	for (int rupID=0; rupID<source.getNumRuptures(); sourceID++) {
		ProbEqkRupture rup = source.getRupture(rupID);
		// do work on rup
	}
}

For many cases (where knowing the source/rup IDs is not important), this could be replaced with the following:

for (ProbEqkSource source : erf) {
	for (ProbEqkRupture rup : source) {
		// do work on rup
	}
}

In order to do this, ERF would have to implement Iterable<ProbEqkSource?>, and ProbEqkSource? would then need to implement Iterable<ProbEqkRupture?>. This would add one method to each:

public Iterator<T> iterator();

What do you think? I don't foresee any adverse impact of adding this.

[Ned Field]

Great idea!

I say go for it...

[Kevin Milner]

done in [8173]! (don't worry Ned, SCEC-VDO updates from your e-mail yesterday are coming!)

[Peter Powers]

I made some modifications to this enhancement, specifically I broadened the scope of the ERF iterable, generifying it in the process. ERF declaration is now:

public interface ERF<T extends ProbEqkSource> extends BaseERF, Iterable<T>

with various methods returning T, e.g.:

@Override
public Iterator<T> iterator() {
	return getSourceList().iterator();
}

AbstractERF declaration is:

public abstract class AbstractERF<T extends ProbEqkSource> implements ERF<T>, ...

This allows AbstractERF subclassers to override getSource(int) and getSourceList() to return more specific Source types. These changes only generated 3 errors is scratch where the new ERF iterable was being used. All subclasses of AbstractERF, however, now have a generics warning. This can be made to go away by updating to:

public SomeERF extends AbstractERF<ProbEqkSource>

in [8277]