[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sc-devel] various classes ==




I think it entirely depends on the the class and what the expected usage is. 
you could say that in some cases you want to test behavior, but then what you should be doing is checking if it implements an interface, and the question shouldn't be "equals" but "implements interface".
but I can see that == is used in Set-scanFor.  
so maybe this interface check is the best in those cases.  it could go wrong at some point, but its less likely I guess.  you could try to put some various things in a Set and have it fail.


as for private vars, for the most part I agree with you.  I just said that you COULD compare instVars if you felt it was relevant in that case.

like CurveWarp
curve is private, but besides class, that is the entire comparison

all the Warp classes (and this is what started my problem with the == lying to me) are basically just testing if the class is the same.

so in some cases compareObject, others "check Interface"


I'll leave the NetAddr etc. alone I think

Env

== { arg that;

^this.compareObject(that,['levels','times','curves','releaseNode','loopNode'])

}


that's nice and to the point I think


should I complain that an EnvEditor might think its equal ?  no, I should test some other way if that's likely.



-cx



On Sat, Feb 23, 2008 at 8:24 PM, Julian Rohrhuber <rohrhuber@xxxxxxxxxxxxxx> wrote:
This is a good move! I think that comparing instVars is not such a
good design, because usually you want to compare behaviour and not
internal state. A variable that is invisible to the outside shouldn't
take part in a comparison. At least I would reserve this for special
cases where it is justified. On the other hand, instVarAt is an
method that gives such an access ... hm.