>
>One of the big selling points of MASON (in my mind) has been that it's
>tuned for speed, even if this isn't quite to aesthetic tastes. A good
>programmer will understand this trade-off.
>

Yes, to me that's the essence. MASON is full of these trade-offs which,
unless you're aware of the relentless ;-) performance focus, may appear
strange at first glance (e.g. lack of generics, the non-inheritance of
Double2D and MutableDouble2D, etc.).

So, to me, there's no big issue in the add method differences, because you
kind of need to be aware in the first place that the mutable and immutable
alternatives exist for a reason (performance). Given that, it makes sense to
keep the interfaces consistent but "interpret" them according to the
mutability criteria.

More generally, I think the MASON documentation needs a prominent "how the
code reflects the performance criteria" section. Put this up front, with a
wide range of (short) examples of why certain things are coded as they are.
(This is also a good advanced Java coding lesson!) Then you've got the
developer approaching the API with the right mindset, and the types of
"surprise" you talk about become less so and more "OK, see why it's like
that...".

Just my tuppence worth (or two cents worth for the US audience).

Regards,
Stuart

Stuart Rossiter - PhD Student, University of Strathclyde