Eliot Miranda-2 wrote
> On Mon, Jul 4, 2016 at 1:58 PM, marcel.taeumel <

> Marcel.Taeumel@

> >
> wrote:
> 
>> Eliot Miranda-2 wrote
>> > On Mon, Jul 4, 2016 at 1:59 PM, Tobias Pape <
>>
>> > Das.Linux@
>>
>> > > wrote:
>> >
>> >>
>> >> On 04.07.2016, at 22:44, Eliot Miranda <
>>
>> > eliot.miranda@
>>
>> > > wrote:
>> >>
>> >> > Hi All, Hi Marcel,
>> >> >
>> >> >     when I see code like this, and there's a lot of it in Morphic,
>> >> >
>> >> > !Flaps class methodsFor: 'testing' stamp: 'mt 5/17/2016 14:17'!
>> >> > anyFlapsVisibleIn: aWorld
>> >> >
>> >> >         aWorld submorphsDo: [:m |
>> >> >                 (m isKindOf: FlapTab) ifTrue: [^ true]].
>> >> >
>> >> >         ^ false! !
>> >> >
>> >> > I think this is performance thrown on the floor (isKindOf: is
>> awfully
>> >> slow, especially in huge hierarchies like Morphic, and bad design,
>> >> restricting one to a concrete class).  And I think that Morph provides
>> a
>> >> perfect place to put an extension that doesn't pollute Object.  So I
>> >> would
>> >> like to see
>> >> >
>> >> > anyFlapsVisibleIn: aWorld
>> >> >
>> >> >         aWorld submorphsDo:
>> >> >                [:m| m isFlapTab ifTrue: [^true]].
>> >> >         ^ false! !
>> >> >
>> >> > with the emphasis on isFlapTab ;-)
>> >>
>> >> Well, class testing seems to be a Morphic pattern, given #findA:
>> (alias
>> >> #submorphOfClass:)
>> >>
>> >
>> > I don't care.  It's *WRONG*.  isKindOf: is a _bug_.
>> >
>> >
>> >>
>> >> Best regards
>> >>         -Tobias
>> >> PS: Not advocating anything just reporting what I found
>> >>
>> >
>> >
>> >
>> > --
>> > _,,,^..^,,,_
>> > best, Eliot
>>
>> Hey Eliot,
>>
>> no, it's not a bug. ;-)
> 
> 
> Yes, isKindOf: *is* a bug, at least in the usage of determining supported
> messages.  Smalltalk has ad-hoc polymorphism that allows any class to
> implement and set of messages, without having to inherit from a
> superclasss
> that defines that set of messages.  isKindOf: breaks this property; it
> restricts the designer to using a concrete class, in violation of the
> language's flexibility.  isKindOf: is therefore most definitely a bug.
> 
> One might think there are valid uses when editing a class hierarchy
> programmatically.  But for this there are messages understood by classes,
> not instances, such as includesBehavior:, inheritsFrom: etc.  These are
> legitimate.  But isKindOf: is not.  It is a horrible hack.
> 
> Although, there is room for improvement. #isFlapTab
>> sounds good. Note that this is not even a critical piece of code because
>> is
>> only called if you open a system window, for example.
>>
>> Try [Flaps anyFlapsVisibleIn: ActiveWorld] bench. It's fast enough. A
>> microsecond here, having around 30 windows open. So, you will not notice
>> a
>> delay. Still, you're right. We should reduce the usage of #isKindOf:.
>>
>> Not polluting Object means still polluting Morph.
>>
>> (Yeah, maybe we should use slower computers to program.)
>>
>> Checks we should consider to add or use more often if it is already
>> there:
>> #isCornerGripMorph
>> #isProportionalSplitterMorph
>> #isCompiledMethod
>> #isColor
>> #isInfiniteForm
>>
>> ... still, a quick look through the usage of #isKindOf: in Morphic code
>> revealed no serious performance issues. We should refactor MenuMorph to
>> not
>> need #isKindOf: that often. This might also be true for other places.
>>
>> The pattern "isClass" is not always a good solution for many cases in the
>> system.
>>
>> Best,
>> Marcel
>>
>>
>>
>> --
>> View this message in context:
>> http://forum.world.st/isKindOf-in-Morphic-code-tp4904890p4904895.html
>> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>>
>>
> 
> 
> -- 
> _,,,^..^,,,_
> best, Eliot

@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.

@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
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.

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



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