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

Re: [Sc-devel] various classes ==

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.

There are a bunch of methods that are written like this:

	== { arg that;
^that respondsTo: #[name, summary, version, author, dependencies, tags, path] and: {(<http://this.name>this.name == <http://that.name>that.name)
			and: {this.summary == that.summary}
			and: {this.version  == that.version}
			and: {this.author  == that.author}
			and: {this.dependencies  == that.dependencies}
			and: {this.tags  == that.tags}
			and: {this.path  == that.path}


	== { arg that;

		^that respondsTo: \path and: { path == that.path }


especially with this last one, ANYTHING that has a path might end up being equal.

I recently added Object-compareObject

which would allow the safer version:

== { arg that;



this also allows you to compare private variables.

	compareObject { arg that,instVarNames;

		if(this === that,{ ^true });

		// possibly ok if one of us isKindOf the other

		if(this.class !== that.class,{ ^false });


			instVarNames.do({ |varname|

if(this.instVarAt(varname) != that.instVarAt(varname),{





			this.instVarSize.do({ arg i;

if(this.instVarAt(i) != that.instVarAt(i),{ ^false });





the only issue/difference would be when comparing objects that aren't of the same class but for the purposes of whatever you are testing it for might be equal.

one example would be Bus vs. SharedBus

but for these rare cases I would just write a custom ==
and it mostly depends on your application.

so does anybody mind if I change these various == implementations ?


Sc-devel mailing list