On Thu, Mar 30, 2017 at 11:06 PM, Stephan Eggermont <stephan@stack.nl> wrote:
> On 30/03/17 16:03, Marc Hanisch via Pharo-users wrote:
>>
>> Reading this, I realized, that I never saw such type-checking in
>> Pharo production code. So the question is, what are recommended
>> design principles for that problem in Smalltalk? Do you use what is
>> called duck typing?
>
>
> Normally I'm not interested in what an object is, but what it can do.
> So a test on #respondsTo: can tell me if the object knows how to do
> something.
>
> In smalltalk, I can add methods to existing classes, so there are a lot of
> extension methods on Object isXYZ, returning false. Morph returns true to
> isMorph, so all subclasses of Morph can be recognized that way.

Many people also technically frown on isXYZ is a similar way to isKindOf:,
but it is a lesser evil and pragmatically is used reasonably often.

>
> Instead of adding a test method, there are also empty implementations

Like this, what you can do is refactor that guarded code into a method #myAction
and add Object>>myAction which throws the exception.
Thus you condense multiple condition statements into
one location and your application code becomes much cleaner.

Object may end up loaded with a lot of methods not of interest to every object,
but the trade-off of cleaner application code is generally worth it.

btw, Here you start to see how using Pharo/Smalltalk "changes the way you think about programming".