[squeak-dev] Re: isKindOf: in Morphic code...
pbpublist at gmail.com
Tue Jul 5 10:13:21 UTC 2016
On Tue, 2016-07-05 at 00:42 -0700, marcel.taeumel wrote:
> @Phil: #isKindOf: is no better or worse than the #isClass-check.
> performance-wise, but arguably not in terms of architecture and code
> While #isClass might be a little closer to idiomatic Smalltalk code,
> should never be used as an excuse for bad design.
It's not an #isClass-check, it's an #isProtocolCollectionCompliant-
check. It is worse both from a performance and an architecture
standpoint to use #isKindOf:. I agree that no amount of calling the
'correct' method (if there are such things) makes up for bad design,
but that's not the argument here.
> @all: I do see beauty in the pattern of asClass/isClass. For example,
> asSet/isSet, asOrderedCollection/isOrderedCollection.
> However, anytime a programmer tends to use a type-check and there is
> "isClass" available, I would rather suggest him to use #isKindOf: for
> moment instead of adding another two methods to encode the "isClass"
> in both
> base class and subclass. Always think twice before blowing up a
> interface. It impedes code readability. Especially if we are talking
> about a
> base class that is already that big, like Morph. Then, if there is
> really no
> other choice -- design-wise -- one has to consider performance.
> is expensive. Okay. Then you can easily add the isClass-check. Fine.
> Sorry, but this is absolutely no black-white decision as Eliot and
We'll have to agree to disagree on this point. Type checking is
fundamentally doing it wrong IMO.
> proposed. There are many factors to consider. Semantics,
> readability, performance, idioms.
> In many cases -- if not all -- I suspect a design issue behind the
> use of
> #isKindOf: or #isClass. Still, I do like #respondsTo: because it is
> to a scenario/domain and leverages the dynamic capabilities of
> For example, "model respondsTo: #foobar" as an extension point in
Don't conflate what these methods are named with the role they perform.
While many of the #is* methods may appear to be class checks, if used
properly they are actually checks for compliance with collections of
protocols. (this would be easier to see if Smalltalk in general did a
better job of formalizing protocols) I understand that many
Smalltalkers don't look at them this way, but I would argue that they
Here are a few examples of why the distinction matters:
1) Proxy objects. If I create a ProtoObject subclass as my proxy
wrapper and pass it into code that does an #isKindOf: check, it will
blow up even though it may be a proxy for exactly the kind of object
being tested for. If it does an #is* check, that will get forwarded to
the actual object and things will work as expected. Don't look at what
I am, look at what I tell you I can do!
2) Parallel and/or alternate class hierarchies that are functionally
equivalent or supersets. Let's say you have created an alternate
hierarchy for Magnitude and its subclasses. If you implement the
appropriate methods and respond true to #is* (i.e. whatever it is
behaving like), why should (most) receivers of these objects need to
know or care that my MyFractionLike objects aren't actually instances
of Fraction, a subclass of it, or even in the Magnitude hierarchy?
3) A class that is close enough and wants to appear to be, but in
reality is something very different from, the thing it responded true
to for #is*. I have a number of things that do this in places in the
class hierarchy that make the most sense from an implementation
standpoint, but not necessarily from a taxonomy standpoint. There are
even one or two places in the base Squeak class hierarchy where
classes aren't necessarily where they 'should' be from a taxonomy
standpoint... so be it.
Testing for behavior, not class name or location in the hierarchy, is
the way to go.
> We should *not* batch-convert all uses of #isKindOf: to an #isClass
> but use our Senders-Tools to hunt down all the design issues left in
More information about the Squeak-dev