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".

Further, the exception thrown by ��Object>>myAction ��

should signal the error on a custom error object, similar to ZeroDivide for example.


> or ones that return self or an appropriate null-value.

Within your framework where you control all the objects��

the Null-object pattern is probably the cleanest OO approach,
but it can't control what the user passes across the public API.
https://en.wikipedia.org/wiki/Null_Object_pattern

btw, you can search null-object pattern in Spotter using " Null #c "
��

cheers -ben