No sweat!

I think you'll find a lot of places where MASON has to strike a balance 
between Java efficiency and traditional design.  We somewhat more often 
come down on the side of Java efficiency, particularly in the core, 
because we're often running MASON on back-end server machines and trying 
to squeeze every drop of blood from it that we can get.  That's why you 
see things like: no use of generics; our own replacement classes for 
certain common Java classes; a distinct aversion to calling objects cast 
into interfaces (which eliminates the ability to do method inlining); 
and so on.  For one big project, one of my students is presently 
cramming 80 million agents into it (and that's not easy!).  I tried hard 
to keep things as obvious for Java coders as we can, but doing so while 
staying maximally efficient is sometimes not trivial.

Sean

Stuart Rossiter wrote:
> Sean,
> 
>    OK, nice answer -- thanks (esp. since it is a side issue). Yes, a
> minor memory hit for speed over many iterations makes perfect sense,
> esp. for visualisations where this is an "optional add-on" to the core
> model.
> 
> Apologies if the original post came across as a "coding lesson". Wasn't
> meant to be: the details just kind of reflected my thought processes in
> thinking about the code alternatives (which were slightly more subtle
> than I'd expected...). I'd be the first to admit that I sometimes get
> hung up on formal OO design principles, instead of the run-time reality :-)
> 
> Regards,
> Stuart