On Tue, Jul 5, 2016 at 12:42 AM, marcel.taeumel <Marcel.Taeumel at hpi.de>
wrote:

> Eliot Miranda-2 wrote
> > On Mon, Jul 4, 2016 at 1:58 PM, marcel.taeumel &lt;
>
> > Marcel.Taeumel@
>
> > &gt;
> > wrote:
> >
> >> Eliot Miranda-2 wrote
> >> > On Mon, Jul 4, 2016 at 1:59 PM, Tobias Pape &lt;
> >>
> >> > Das.Linux@
> >>
> >> > &gt; wrote:
> >> >
> >> >>
> >> >> On 04.07.2016, at 22:44, Eliot Miranda &lt;
> >>
> >> > eliot.miranda@
> >>
> >> > &gt; 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.
>

That's simply incorrect, and misunderstands Smalltalk dynamic typing.  And
it is precisely in terms of architecture and design that it is worse
(although in performance terms it is terrible, especially when
disconfirming membership).  Consider Random and ReadStream.

Random inherits from Object, not PositionableStream, yet it provides a
subset of the Stream interface via next, next: and next:into:.
PositionableStream provides the layout of inst vars that used to be
expected by the VM primitives for next, nextPut: and position that used to
be required for performance but no longer are.  So there is no practical
benefit to have Random inherit from PositionableStream, but Random *is* a
Stream.  So were we to want to test for streamness we *could* implement
isStream in both PostionableStream and Random to answer true and in Object
to answer false, but we *could not* use aRandom isKindOf:
PositionableStream.

So as I stated before, isFoo supports ad-hoc polymorphism, allowing the
designer to use inheritance for reuse, and freeing them from (mis) using it
for "type".  Whereas isKindOf: restricts designs to increasingly rigid and
brittle class hierarchies, which prevent natural Smalltalk style by a
broken convention.

So Phil simply misunderstands the issue.  I stand by my assertion, backed
by 35 years of Smalltalk programming, that isKindOf: _is a bug_.


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

isKindOf: is simply lazy.  It's easy to implement the isFoo pattern, and it
can be commented properly (for example, the comment can specify exactly
which selectors the truth of the message implies).  isKindOf: is quick and
dirty, but potentially ambiguous. Precisely what API are we expecting the
receiver to exhibit?  Ugh.



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

Agreed.  If isKindOf: can be removed by better design, especially by double
dispatching then great.  But in cases where isKindOf: is used exclusively
on general instances of some class other than Object (such as Morph), or
arguably this and nil as well, replacing isKindOf: invocations can be done
without polluting Object, and can provide much better documentation and
performance, as well as the key design flexibility it provides.


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


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160705/ba7284ac/attachment-0001.htm