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

[Phil B]

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 <
cuis-dev at lists.cuis.st> 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
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20190806/48851757/attachment.htm>