> >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