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

keith keith_hodges at yahoo.co.uk
Thu Mar 4 19:38:52 UTC 2010

Another way of doing this, (last seen in SmalltalkAgents) is to  
implement askFor:

anObject askFor: #isMorph.

We had an ongoing debate on mantis as to whether this should return  
nil or false by default. (I prefer false, my more purist friends  
appear to prefer nil) if the selector is not implemented. I would  
favour this approach because askFor: is useful for other purposes, and  
in a world where things are more modular and less tightly coupled, it  
can be useful to have askFor: and askFor: aSelector ifAbsent:


so that the traditional isXX selectors still work, but

> 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:  
> #SketchEditorMorph
> 	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].
> 	^false
> 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