[squeak-dev] Re: isKindOf: in Morphic code...

marcel.taeumel Marcel.Taeumel at hpi.de
Tue Jul 5 10:33:50 UTC 2016


Phil (list) wrote
> Marcel,
> 
> On Tue, 2016-07-05 at 00:42 -0700, marcel.taeumel wrote:
>> 
>> 
>> @Phil: #isKindOf: is no better or worse than the #isClass-check.
>> Maybe
>> performance-wise, but arguably not in terms of architecture and code
>> design.
>> While #isClass might be a little closer to idiomatic Smalltalk code,
>> it
>> 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
>> no
>> "isClass" available, I would rather suggest him to use #isKindOf: for
>> the
>> moment instead of adding another two methods to encode the "isClass"
>> in both
>> base class and subclass. Always think twice before blowing up a
>> class'
>> 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.
>> #isKindOf:
>> is expensive. Okay. Then you can easily add the isClass-check. Fine.
>> 
>> Sorry, but this is absolutely no black-white decision as Eliot and
>> Phil
> 
> 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,
>> code/interface
>> 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
>> specific
>> to a scenario/domain and leverages the dynamic capabilities of
>> Smalltalk.
>> For example, "model respondsTo: #foobar" as an extension point in
>> graphical
>> widgets.
>> 
> 
> 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
> should.
> 
> 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.
> 
> Thanks,
> Phil
> 
>> We should *not* batch-convert all uses of #isKindOf: to an #isClass
>> check
>> but use our Senders-Tools to hunt down all the design issues left in
>> the
>> system.
>> 
>> Best,
>> Marcel
>> 
>> 

Hi Phil,

code lives. It should get improved if new requirements become obvious.
#isKindOf: can be a valid (itermediate) step on this road of code evolution.
You cannot account for any possible extension points of applications that
might be created in the system. This is what refactoring is for.

If an #isClass check is added, it will become part of the interface and
callable from any application. If it remains an #isKindOf: check, it might
still evolve towards not needing such a check at all. Removing an #isClass
check later might break applications that already rely on it.

So, like many parts in the system, using #isKindOf: can be seen as an
intermediate step. Now, programmers should be encouraged to also go the next
step and think about whether it should become an #isClass check or whether
the check is necessary at all. Such a decision cannot be made by a computer
progam / automatically. Programmers have to review the code, think about it,
decide, and implement/refactor.

Calling this phenomenon a "bug" does not feel right. It feels like a blame
on some particular developers. I don't think it is.

We only have so much time.

Best,
Marcel



--
View this message in context: http://forum.world.st/isKindOf-in-Morphic-code-tp4904890p4904965.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.


More information about the Squeak-dev mailing list