Re: [Pharo-users] type checking in Smalltalk
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. Instead of adding a test method, there are also empty implementations or ones that return self or an appropriate null-value. Stephan
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
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 <btc@openinworld.com> wrote:
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
-- Best regards, Igor Stasenko.
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 <siguctua@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 <btc@openinworld.com> wrote:
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
-- Best regards, Igor Stasenko.
participants (4)
-
Ben Coman -
Igor Stasenko -
Marc Hanisch -
Stephan Eggermont