does squeak have an equivalent of #askFor:

I remeber a while back using #askFor:

which does something like.
------------
askFor: selector

^(self respondsTo: selector) ifTrue: [ self perform: selector ] ifFalse:
[ false ].
------------

is used for testing isThis and isThat's

a askFor: #isMyclass

best regards

Keith


               
___________________________________________________________
Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html

Ouch!
IMHO a lot of #isThis or #isThat shows the lack of some abstractions.
Maybe you can solve it a better way.



On 8/11/06, Keith Hodges <[hidden email]> wrote:

Hi!

Keith Hodges <[hidden email]> wrote:
It seems to me that there is a much simpler pattern to use if you want
to be able to ask an object if it "is" something.
The normal approach is to let all classes that think they are bananas
implement isBanana as "^true" and then let all others implement isBanana
as "^false". The above technique only has one advantage and that is that
you do not need to let all others implement isBanana, but this is
Smalltalk - it does not hurt to let them. :)

Depending on if you know a little bit about what classes are possible -
you can put the "^false" implementation(s) in different places. Perhaps
you have some abstract base class(es) that you can put it in. Or if you
really want to be able to test *any* object - put it in the class
Object. Using PackageInfo/Monticello you can easily mark that method as
an extension method that still belongs to your Monticello package. And
of course this is much faster than using respondsTo: and perform:.

But of course, I too use repondsTo: and perform: now and then - so I am
not saying it is forbidden in general.

regards, Göran

Diego Fernandez wrote:
> Ouch!
> IMHO a lot of #isThis or #isThat shows the lack of some abstractions.
> Maybe you can solve it a better way.
>
why?

Keith


               
___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

On 8/12/06, Keith Hodges <[hidden email]> wrote:
> Diego Fernandez wrote:
> > Ouch!
> > IMHO a lot of #isThis or #isThat shows the lack of some abstractions.
> > Maybe you can solve it a better way.
> >
> why?

Because if you have an object that responds to isBanana method, you
end with code like this:
anObject isBanana ifTrue: [ "do something with anObject" ]
                             ifFalse: [ "do another thing with anObject" ].

"do something..."/"do another thing" is behavior specific to anObject,
so why is not a message to anObject? Why you can't have a message
polymorphic to "bananas" and "non-bananas"?
There are cases when is more simply to have the #isMethod.
But each time that I found cases like this, I think: What is the
abstraction that I'm missing?
My rule of thumb is: Avoid ifTrue/ifFalse...:P
Each "if" is a decision, a behavior specific to an object, so in most
cases it can be resolved using messages sends. (I'm not saying that is
easy to do that, and in complex cases maybe the "if" is better, but
thinking about the design and what is missing that you need the "if"
is a good practice).

Regards,
Diego

Diego Fernandez wrote:
> My rule of thumb is: Avoid ifTrue/ifFalse...:P
> Each "if" is a decision, a behavior specific to an object, so in most
> cases it can be resolved using messages sends.

well one could also say that each "if" is a question send to an object.
what's wrong with asking questions to objects ?

Stef

Hi!

"Diego Fernandez" <[hidden email]> wrote:
And I fully agree of course. Normally the perceived need for an isBanana
message *can and should* be solved using a different design leveraging
polymorphism/delegation properly. BUT... in design there are always
tradeoffs and sometimes you just decide that an isBanan message is still
the way you want to go. At leat that is my experience, perhaps I could
have redesigned my way around the isBananas that I have written - but I
doubt it.

regards, Göran

Il giorno dom, 13/08/2006 alle 23.42 +0200, [hidden email] ha scritto:
I find the isBanana-style messages are useful when I have a collection
of diverse objects, and I want to retrieve Bananas only:

        aCollection select: [:each | each isBanana ]

        Giovanni