[squeak-dev] Re: Object>>#is:? (was: Re: PackageDependencyTest)

Andreas Raab andreas.raab at gmx.de
Thu Mar 4 18:58:50 UTC 2010

For discussion, this is what I'm suggesting:

Object>>is: aSymbol

	"A generic membership test. Should be used to avoid the proliferation 
of isXXX
	methods where appropriate. Use it like here:

		FooBar>>is: aSymbol
			^aSymbol == #Foo or:[aSymbol == #Bar or:[super is: aSymbol]]

	This implementation can also be used with class names to replace the usage
	of aMorph isKindOf: SketchEditorMorph with, e.g.,  aMorph is: 
	to avoid unnecessary dependencies on classes"

	"Check to see if aSymbol is a class name in the receiver's environment"
	self class environment
			at: aSymbol
			ifPresent:[:aClass| ^self isKindOf: aClass].


On 3/4/2010 10:50 AM, Chris Muller wrote:
> Andreas wrote:
>>         (foo isKindOf: FooBarMorph) ifTrue:[...]
>> is completely pointless. If you're writing this already, you might as well
>> avoid that dependency and write:
>>         (foo is: #FooBarMorph) ifTrue:[...]
>> etc. I'd really like to see #is: integrated so that it can used
>> interchangeably with #isKindOf: but using the name instead of the type.
> That would be a great method for helping to avoid hard dependencies.
> My only suggestion would be for us to consider the namespace.  It
> might be a shame to consume beautifully terse #is: for something as
> mundane as a package-existence / type-check.
> Applications might already, or want to, use #is:.  However, any
> overrides of #is: will rob them of the functionality provided by
> Object>>#is:, so a complication is introduced, a choice is forced.
> Ok, I might be wrong in a practical-sense about this, since the
> package-existence check would typically be on a PackageInfo object or
> something that probably wouldn't otherwise need #is:.
> My only point is that, we should remember to duly consider the
> namespace when consuming a selector as grand as #is: in case it might
> be better-appreciated in the application namespace..
> Regards,
>    Chris

More information about the Squeak-dev mailing list