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