On Fri, Feb 11, 2011 at 02:51:26AM +0100, Levente Uzonyi wrote:
> On Fri, 11 Feb 2011, Igor Stasenko wrote:
> 
> >On 11 February 2011 02:28, David T. Lewis <lewis at mail.msen.com> wrote:
> >>We had a good deal of discussion earlier about adding Object>>is:
> >>with an inconclusive outcome:
> >>?http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-April/148501.html
> >>
> >>Igor's original proposal is:
> >>?http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-June/136793.html
> >>
> >>I have been tinkering around with Juan's SimpleMorphic in hopes of
> >>getting it running in Squeak alongside MVC and Morphic, and it would
> >>be convenient to have the default implementation of #is: in the image
> >>so I don't have to put it in a package override.
> >>
> >
> >Just yesterday i had  discussion about this with people in the lab. I
> >can't say that i heard something new regarding this,
> >and not saying that i'd like to resurrect the discussion.
> >So, in short: there was no objection concerning getting rid of isXXX
> >in favor of using #is: method.
> 
> What about performance?

I do not think that Juan would have chosen to use the #is: idiom for
his Cuis Morphic implementation if he thought that performance would
be a problem. It seems to work well.

> 
> >The only thing which still looks controversial is too simple default
> >implementation which answers false.
> >
> >To my current opinion, Juan's variant is preferable. :) Yes. it should
> >answer false and don't contain any extra logic , like trying to follow
> >class hierarchy etc.

My intention is to include the method copied directly from Cuis, which is:

is: aSymbol
	"A means for cleanly replacing all isXXX like methods.
	Please use judiciously!
	Suggested by Igor Stasenko at
	http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-June/136793.html"

	^false

> >Because it serves to replace isXXXX pattern, and not adding something
> >new (i.e. more 'userful'). So, answering false for Object class fits
> >well for this purpose.
> >
> >And of course solution to that problem is simple:
> >- avoid writing code in style, which require isXXX tests and then
> >branching. Nicely written code should use message dispatch instead.
> >Too bad, we are not living in perfect world :)
> 
> Is it better to flood superclasses with no-op extension methods?
> 

Absolutely no. But the proposal is from June 2009 and was supported
by Andreas, whose judgement I trust a lot. This is the first time in
over 10 years of squeaking that I have ever suggested adding a method
to Object, so it's really not too much of a flood. And I promise
never to do it again ;-)

Dave