isKindOf: vs. isClassX methods

Torge Husfeldt jean-jacques.gelee at gmx.de
Thu Oct 11 12:38:54 UTC 2001


Hi Scott, Hi all,

I think you are missing one or two points.

Firstly(Scott), your test for implementing an interface is slightly to
simplistic:
regard the situation when a message is implemented as 'self
shouldNotImplemen'
which is bad tyle but cannot always be avoided.

Secondly(all), in the situation where you do a 'readFromString:' you
really want to check the class of the returned object, not it's
protocol, because it may coincidentally be syntactically correct but not
semantically.  I.e. when i get a string from the user (like in another
thread) and I say 'Point fromString: userString' then I generally want
to have a Point subInstance. Otherwise I would have written '(Object
fromString: userString) doSomethingDependingOnYourTypeWithArguments:
myArgs'.

Thirdly, I wrote once a little snippet of code (and posted it to the
list) that programmatically recompiled all calls of 'isKindOf:' which
referred to a class statically
to use the isXYZ form instead (these where compiled on the fly as
appropriate) and nobody seemed to care. 

Scott A Crosby wrote:
> 
> On Wed, 10 Oct 2001, Andreas Raab wrote:
> 
> > Scott,
> >
> > You're a kidder, eh?! You can't mean seriously what you've written, but I'll
> > respond to it anyways ;-)
> >
> 
> I did, and thanks, it is instructive.
> 
> What it is is confusing two things, sometimes, you do care about the
> actual class, because your code does need to get into the grotty
> implementation. Here, using isKindOf: is important. In my case for some
> code I did recently (the 33% gain with macroBenchmark1), I did need
> isKindOf, in this sense of things.
> 
> But then you have the other case, where you want to know if it supports a
> particular set of methods, the java notion of an interface.
> 
> I hadn't realized quite how important the second case was until your
> response. Thanks!
> 
> Query, why not do what you mean instead of creating extra methods like
> isXYZ?  Support something that lets you directly represent interfaces and
> implementation.
> 
> Basically, create classes which inherit from Interface, then
> define something that does exactly that, something like:
> 
> Object>>implementsInterface: anInterface
>   anInterface class selectorsDo: [ :x | self class canUnderstand: x
> ifFalse:
>       [^false]].
>   ^true.
> 
> Well, actually, slightly more complicated to handle interfaces inheriting
> >from other interfaces, but you get the idea.
> 
> And don't tell me that it'll be too slow! Cause we can do my favorite
> thing: cache the results.  (If there are, say, 200 classes each of which
> gets checked whether it implements, say, 4 interfaces, thats <1k of
> hash table slots, say, 16kb for a cache.)
> 
> For bonus points, I could integrate this into Behavior (or whatever) and
> let one verify that a class does support the interfaces it claims to
> support. Further integration into browsers and other foo is not something
> I wanna do. :)
> 
> Good, Bad, Tried already, or Ugly?
> 
> > important. And then you have go back and fix it at three zillion different
> > places (some of which might even be out of your control).
> 
> Ouch... Your point stands, and I bask in your knowledge. :)
> 
> Scott




More information about the Squeak-dev mailing list