<div dir="auto"><div>Two main use cases off the top of my head:<div dir="auto"> </div><div dir="auto">1) Sometimes I'm doing an assert: (x is #Foo) where I need to check behavior, not type, in the assertion. (#respondsTo: is too granular)</div><div dir="auto"> </div><div dir="auto">2) Dynamic dispatch. A recent example that comes to mind is a clipboard object handler where I had a dynamic dispatcher that is generated dynamically at runtime based on what packages are loaded when it is called.</div><div dir="auto"> </div>Polymorphism is a great tool, but it's not always the right tool.</div><div dir="auto"> <div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Tue, Aug 6, 2019, 5:55 PM Andres Valloud via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If one is willing to implement #is: and friends so that one can write (x is: #Blah) ifTrue: [x doSomething] then why not just write the following? x doSomethingIfBlah It's essentially the same number of methods, and if too many of those start accumulating in Object then you know there's a design problem that should be fixed rather than accommodated. Also, it's way faster because now there are fewer message sends, and the code is delegating the class / protocol checks to the VM (which was there to provide that functionality in the first place). On 8/6/19 14:08, Phil B wrote: > I've always seen the value as being two-fold: > > 1) To avoid needing to implement N #is* methods on Object (and there's a > lot more of this out there than just what the base image implements and > uses) > > 2) As a mechanism to test for *protocol* compliance rather than *class* > membership of an object. One may or may not agree with this > interpretation, but lacking a definition that said otherwise, I decided > it meant this as well 😀 > > While implementations in the base image tend to have a 1:1 relationship > with a particular class, it is not required. For example, I have a > number of classes that return true for #is: which aren't actually > subclasses of the thing they return true for but do behave as if they > were. I don't care so much if a given object isKindOf: Morph, but > rather if it behaves as one. > > There was a time when I tried to make the second use case more explicit > but there didn't seem to be a interest from others. So I may be the > only person who makes use of the second use case today. If so and 1 > isn't seen as a worthwhile reason to stick with this approach, I can do > this another way. > > On Tue, Aug 6, 2019, 3:21 PM Andres Valloud via Cuis-dev > <<a href="mailto:cuis-dev@lists.cuis.st" target="_blank" rel="noreferrer">cuis-dev@lists.cuis.st</a> <mailto:<a href="mailto:cuis-dev@lists.cuis.st" target="_blank" rel="noreferrer">cuis-dev@lists.cuis.st</a>>> wrote: > > So it looks like the #is: methods are there to implement the > functionality of #isXYZ messages with half the methods, which in turn > are there presumably to avoid having to send class or #isKindOf:. But > one way or another, they are still class checks done in the language, > when the system already provides fast and invisible class checking in > every message send. > > In an old Cuis image that I have handy right now, there are 30 > implementors of #is:. There are 120 senders, but (essentially) 30 of > those are the implementors just mentioned. So, 90 senders for 30 > methods, a use factor of 3. A brief look suggests a histogram, which > yields the following arguments for #is: (excluding the implementors > themselves). > > #(#Text #Color #Morph #Morph #Text #Morph #Form #Text #Morph #Form > #Text > #Text #Text #Form #Morph #Text #PluggableButtonMorph #CompiledMethod > #Morph #Color #Color #ColorForm #CompiledMethod #Stream #Text #Stream > #Morph #DateAndTime #DateAndTime #DateAndTime #DateAndTime #DateAndTime > #Text #Array #HandMorph #InnerTextMorph #InnerTextMorph #SystemWindow > #SystemWindow #HandMorph #MessageSend #Color #Text #ScrollPane > #CompiledMethod #Text #HandMorph #MenuItemMorph #MenuItemMorph > #MenuItemMorph #MenuItemMorph #UpdatingMenuItemMorph > #UpdatingMenuItemMorph #LayoutMorph #HandMorph #CompiledMethod #Stream > #Stream #Text #HandMorph #SystemWindow #HandMorph #MorphicEvent #Morph > #HaloMorph #Stream #Text #Text #HaloMorph #SystemWindow #Taskbar > #SystemWindow #SystemWindow #MessageSend #refusingToAccept #Text > #Rectangle #Rectangle #Rectangle #Rectangle #Rectangle #Text > #hasTextProvider #hasTextProvider #Stream #Text #Text #Text > #CompiledMethod #SystemWindow #SystemWindow #PluggableListMorph > #SystemWindow #SystemWindow #Taskbar #Text #Morph #Text #Text #Text > #DateAndTime #DateAndTime #DateAndTime #DateAndTime #DateAndTime > #UpdatingMenuItemMorph #ColorForm #MessageSend #MessageSend #Morph > #Morph) > > As a set, this collection has a size of 25 (so already this suggests > dead code is present). Further, as an actual histogram, we see this: > > #Text -> 23 > #Morph -> 11 > #DateAndTime -> 10 > #SystemWindow -> 10 > #Stream -> 6 > #HandMorph -> 6 > #Rectangle -> 5 > #CompiledMethod -> 5 > #MessageSend -> 4 > #Color -> 4 > #MenuItemMorph -> 4 > #UpdatingMenuItemMorph -> 3 > #Form -> 3 > #hasTextProvider -> 2 > #HaloMorph -> 2 > #Taskbar -> 2 > #ColorForm -> 2 > #InnerTextMorph -> 2 > #PluggableButtonMorph -> 1 > #LayoutMorph -> 1 > #Array -> 1 > #refusingToAccept -> 1 > #PluggableListMorph -> 1 > #ScrollPane -> 1 > #MorphicEvent -> 1 > > which suggests there is something going on, design-wise, with the top > 20% because together they account for much more than 50% of the usage. > > So, even though as syntax I would find it just fine, I wonder if this > improvement is optimizing the highest priority problem. > > What has been the evolution / usage of this feature over time? Where > should it go from here? > > On 8/6/19 04:54, Juan Vuletich via Cuis-dev wrote: > > Hi Folks, > > > > One thing I don't like about the #is: message is that being a > keyword, > > it usually requires parenthesis. Today I realized we can use #? > instead. > > So, we could write: > > > > aForm ? #GrayForm ifTrue: [ self doSomething ]. > > > > instead of > > > > (aForm is: #GrayForm) ifTrue: [ self doSomething ]. > > > > Do you like it? What do you prefer, #is: or #? ? Reasons for > adopting or > > not adopting it? > > > > Thanks, > > > -- > Cuis-dev mailing list > <a href="mailto:Cuis-dev@lists.cuis.st" target="_blank" rel="noreferrer">Cuis-dev@lists.cuis.st</a> <mailto:<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank" rel="noreferrer">Cuis-dev@lists.cuis.st</a>> > <a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a> > -- Cuis-dev mailing list <a href="mailto:Cuis-dev@lists.cuis.st" target="_blank" rel="noreferrer">Cuis-dev@lists.cuis.st</a> <a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a> </blockquote></div></div></div>