> On 05-07-2016, at 12:45 AM, marcel.taeumel <Marcel.Taeumel at hpi.de> wrote:
> 
> One more thing: If you really consider to implement the "isClass" check in
> two unrelated branches of an inheritance tree, you arguably have a design
> issue. Just use #respondsTo:. For example, TranscriptStream should not
> implement #isModel but rather implement the Model interface as needed.
> #respondsTo: will work fine.

I disagree. Not to checking for protocol but to using #respondsTo: - it’s even slower that isKindOf: ! It doesn’t simply climb the class tree checking the class name, it climbs the class tree checking the name of every method in the methodDictionary!

The big issue is the design failure implied by the use of this sort of test; we ought to solve as many of those as possible as soon as possible. Swapping an isKindOf: for some isFoo usage is not ideal by any stretch of the imagination but it can at least solve some important performance problems and it at least allows for multiple classes in disjoint hierarchies to respond sensibly. A better choice of names will often help make life clearer  - for example #canBeButtonMorphLabel would be much better than #isStringMorph. At least that hints at a protocol test rather class membership.

We could, of course, implement a real protocol management & testing capability. At one time I thought that Traits might do that but they went moribund before ever really coming to life.


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
An elephant is a mouse with an operating system.