[Insight-developers] A few minor consistency issues

[Zachary Pincus]

I guess I was thrown off the trail by comments like:
>   /** Set the functor object.  This replaces the current Functor  
> with a
>    * copy of the specified Functor. This allows the user to specify a
>    * functor that has ivars set differently than the default functor.
>    * This method requires an operator!=() be defined on the functor
>    * (or the compiler's default implementation of operator!=() being
>    * appropriate). */

in the Functor image filters. Thank you guys for setting me straight  
on this score!

>> I guess this assumption was false. If so, then the only way
>> to properly compare two arbitrary instances would be to
>> manually do the memory location comparison, right?
>>
>
> Not sure what you mean. In general you can't compare 'raw' memory  
> locations.

Sorry, didn't write clearly. I was referring to comparing the address  
of each object for equality (e.g. what Python does when lacking an  
__eq__ method), and just assuming that any objects which are not in  
the same memory location are different.

Anyhow, with regard to Luis's suggestion that the best approach here  
is to add operator== and != to all functor objects, I have some small  
reservations. Specifically, this requirement is new, non-obvious, and  
only makes itself known if a user tries to use a method like  
SetFunctor. This combination could be a recipe for developer  
frustration, unless it is documented very clearly in all the classes  
that take functors (and the incorrect and conflicting documentation  
such as above are removed).

So as long as we're doing "good-for-our-health" exercises, we should  
make sure to do that part too.

There is an other option, though: doing python-style "default"  
comparisons-of-memory-address in the FunctorImageFiler classes. This  
would make it easier for people who want to write simple functors.  
Also, since there are functors not in the itk::Functor namespace even  
in ITK (e.g. Add3 functor is in itk::Function), this option would  
decrease the chances of errors on our side. It's a little less in  
keeping with the C++ spirit, and provides a little less protection  
against getting the MTime set wrong, though.

I don't have any preference in the matter, but I thought I would  
mention these issues. The solution probably doesn't really matter,  
since this is such a minor corner case that it didn't come up until now.

Zach