Re: [Pharo-users] type checking in Smalltalk

[Marc Hanisch via Pharo-users]

--- Begin Message ---

Thanks for that many responses! :-)

I think I get the picture! In JavaScript I do that type checking because
although I get an error, when requesting a method that is not defined, I do
not get one when requesting or setting a property that does not exists.
Much more worse in PHP before version 7.0 I get an error, which can not be
handled by try / except - but not an exception object.

Great to know that I can keep the code clean in Smalltalk as I get an
exception every time I try to send a message that is unknow to the receiver!

Best regards,
Marc

2017-03-31 12:31 GMT+02:00 Igor Stasenko <siguc...@gmail.com>:

> In other words: don't ask - tell.
> Instead of writing something like:
>
> object isSomething ifTrue: [ object doSomething ] ifFalse: [ object
> doSomethingElse ]
>
> just write it:
> object doSomething
>
> that gives you much less code bloat, and much clear view of your intent(s)
> and  even in case of exception , you can always interpret DNU as "object
> are missing feature, you asked for", which is again, reveals your intent.
>
> Also things like:
>
> object isSomething ifTrue: [ self doSomethingWith: object ] ifFalse: [
> self doSomethingElseWith: object ]
>
> in general considered as anti-pattern, because you basically implementing
> polymorphic behavior in wrong place i.e. in code that using object, instead
> of code that belongs to the object itself.
>
>
> On 31 March 2017 at 03:05, Ben Coman <b...@openinworld.com> wrote:
>
>>
>>
>> On Thu, Mar 30, 2017 at 11:06 PM, Stephan Eggermont <step...@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
>>
>>
>
>
> --
> Best regards,
> Igor Stasenko.
>

--- End Message ---