It's not terribly OO, I agree. It's useful in a kind've pattern
matching-y way (albeit pattern matching lite). I used it deliberately
when playing around with derivative parsing. Take a look at
#isNullableBlock here:
https://github.com/frankshearar/Parsing-Derivatives/blob/master/Derivatives/DerivingParser.st

isNullableBlock
    | n |
    n := nil.
    n := [:p |
        p class caseOf: {
            [Empty] -> [false].
            [EmptyString] -> [true].
            [EpsStar] -> [true].
            [Literal] -> [false].
            [LiteralSet] -> [false].
            [Union] -> [(n value: p left) or: [n value: p right]].
            [Cat] -> [(n value: p first) and: [n value: p second]].
            [Red] -> [n value: p parser].
            [StarParser] -> [(n value: p parser) or: [p parser isEmpty]].
            [DelayedParser] -> [n value: p force].
            [DelegateParser] -> [n value: p parser]}
        otherwise: [Error signal: 'isNullable not defined for ', p
className]] lfpWithBottom: false.
    ^ n.

(We're _effectively_ using #isMemberOf: (I think? I can never remember
which is "is this class" and which is "is this class or subclass") by
switching on `p class`.)

I switch on type here because I'm much more interested here in the
algorithm, and I can concentrate the whole thing into one place,
rather than use implementors-of to view and a Browser to extend.

But if you could mark methods as belonging to the same "conceptually
same method split into multiple parts like a type-switching pattern
match" you could have a special Browser assemble all the parts to
display them together, as well as make it easily to extend the
"partial method". When you use Traits the Browser +
SystemChangeNotification stuff lets you do all sorts of nifty things
that feel like you're working with (lisp) macros while also letting it
look like everything's flattened. We need more of that.

frank

On 1 September 2013 04:30, Casey Ransberger <casey.obrien.r at gmail.com> wrote:
> Totally. Also, one might argue that switching on type isn't terribly
> object-oriented. Or rather, it sort of re-implements dispatch. Sometimes
> it's hard to avoid, but some hard things are worth doing. Of course I'm a
> big fat hypocrite once in a long while (DNU hacks, #isKindOf:, etc.)
>
> #respondsTo: is nicer in some spots. Protocol isn't class. Etc.
>
> +1
>
>
> On Sat, Aug 31, 2013 at 7:39 PM, tim Rowledge <tim at rowledge.org> wrote:
>>
>> There are 623 senders of isKindOf: in the 4.5 image I'm using right now -
>> which may be more than the general because I have some extra stuff loaded -
>> and I'd bet that there are no more than a dozen places where it is actually
>> a sensible way of doing what is needed.
>>
>> It's slow - it scans up a class tree.
>> It's ugly.
>> It isn't actually testing what a lot of people seem to think - if you want
>> to find out is some object can handle a certain capability try actually
>> asking with something like  #isAGraphicThing rather than (isKindOf: Morph)
>> or:[ foo isKindOf: DisplayObject] blahblahblah.
>>
>> We can do better.
>>
>> tim
>> --
>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>> Useful random insult:- Paralyzed from the neck up.
>>
>>
>>
>
>
>
> --
> Casey Ransberger
>
>
>