[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:
#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
|