On 30/10/2009, at 7:05 AM, Miles Parker wrote:

>
> On Oct 29, 2009, at 12:04 PM, Sean Luke wrote:
>
>> [Miles's message didn't appear to get through]
>>
>> Thanks Miles.  A couple points:
>>
>> - I gather from this that you would find "functional" (non- 
>> modifying) style to be surprising.  This is interesting because  
>> it's not what I would intuitively expect would be the hope of most  
>> coders.
>
> I guess I should say that the semantics of that are pretty much  
> always unclear to me. I'm not surprised because I'm already  
> unsure.. :) I expect that value to be returned, but I also "worry"  
> that the value had been modified.  The problem is that Java has  
> trained me to see any method calls as potentially modifying. See  
> what I mean?

Well it's part of Java as an OOP language that you expect  
object.method(input) to change the state of the object, even if it's  
returning something (and you're doing assignment with that). Maybe  
it's not such a good thing that back in undergrad I was taught to  
watch out for cases like that, but so be it.
If I was using an FP language then I'd expect that not to happen.  
Those are the ideal cases anyway, but the world is not ideal :)

> Or I've been using the Provider pattern a lot recently, probably  
> because Eclipse is so deep into them. But it's kind of cool, because  
> you can just do something like..
>
> interface LocationProvider {
>   double getX(Object o);
>   double getY(Object o);
>   double getZ(Object o);
>   boolean is3D(Object o);
> }
>
> Assume you know what kinds of locations will be in your space, i.e.  
> they aren't mixed. What you do is provide an adapter that returns a  
> provider appropriate for the set. If they are you're going to have  
> to decode types then you'd have to do instanceof which isn't  
> terribly pretty but just fine for a lot of usages.
>
> MasonMutable2DLocationProvider {
> 	getX(Object o) {
> 		return ((MutableDouble2D) o).getX();
> 	}
> ...
> }
>
> MasonImmutable2DLocationProvider {
> 	getX(Object o) {
> 		return ((Double2D) o).x;
> 	}
> ...
> }
>


<snip>

That is kind-of cool. :)

On 30/10/2009, at 4:33 AM, glen e. p. ropella wrote:

> Thus spake Sean Luke circa 10/29/2009 10:27 AM:
>> It's always been efficiency.
>
> Then I'd definitely opt for (B), keep the mutables mutating.

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.

Cheers,
Dr Matthew Berryman
Defence and Systems Institute
SPRI Building
University of South Australia
Mawson Lakes  SA  5095
t +61 8 8302 5882
f +61 8 8302 5344
m +61 413 458 594
CRICOS Provider Number: 00121B