is* methods

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

is* methods

Blake-23
Hello, all:

        While wandering through the (hefty) base Object class, I came across the  
is* methods, which I had of course used many times.

        They're very convenient.

        But are they, well, stupid? Something like 40 methods that all return  
false and are overridden by one class somewhere in the hierarchy? Wouldn't  
their purpose be better served by a single method, like:

is: Class
    ^(self class) inheritsFrom: Class

which would never have to be overridden? Obviously there are some is*  
methods that server a larger purpose but isn't more...polymorphic...to say

is: String
is: Morph
is: SomeNewClass

rather than

isString
isMorph

and then add "isSomeNewClass" when you need it?

        ===Blake===
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: is* methods

Michael Rueger-6
Blake wrote:
> Hello, all:
>
>     While wandering through the (hefty) base Object class, I came across
> the is* methods, which I had of course used many times.
>
>     They're very convenient.

Yes, but the mantra should be: "Convenience is the death of good design"

> is: Class
>    ^(self class) inheritsFrom: Class

isKindOf: already exists.

> which would never have to be overridden? Obviously there are some is*
> methods that server a larger purpose but isn't more...polymorphic...to say

is* is much much faster

But, as I said, using is* is a sign of a design problem. If you use is*
you are hardwiring the knowledge about certain classes into your
architecture.

Michael

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners