[Cuis-dev] Poll: ? instead of is: ?

[Andres Valloud]

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