[Pharo-users] Why is #findString: in accessing?

Richard O'Keefe raoknz at gmail.com
Wed Feb 27 18:53:01 EST 2019

In my own Smalltalk, a string understands a little over two thousand
selectors, of which about 440 are specific to strings, the others
being shared by other sequences.  That's quite a lot to search through.
As it happens, I *do* have a 'searching' category and the
#findString:[startingAt:][ignoringCase:][ifAbsent:] methods are
in it.  The methods defined in the ANSI Smalltalk standard are
and are quite easy to find once you recall that methods for searching
in a sequence generally have 'find' or 'indexOf' in their name.

It is surprisingly hard to keep categories consistent.  If there is
a way to say "here I am browsing method M in category G of class C,
is there an ancestor of C that puts the selector of M in a different
category?" I would love to know it.  (Adding such a code critic to
my Smalltalk is on the TODO list.)

On Tue, 26 Feb 2019 at 00:20, Tim Mackinnon <tim at testit.works> wrote:

> I always struggle (even after years of casually using smalltalk) to find
> the String methods that do the heavy lifting (and are comparable to other
> languages). The methods are normally there, but they often have names that
> don’t compare well with other languages.
> I think that what doesn’t help is the categorisation of methods in String
> - for example - if I want to do some searching in a String - why is
> #findString: in ‘accessing’ - I totally didn’t think to look in there. To
> be honest, I really wanted a protocol called ‘searching’ - but its not
> there?
> I find the protocols in the system to be pretty bad in all honesty. Its a
> good idea, but I don’t think its clear on whether its protocol, or
> category. And if the former - where are the tools to help ensure things
> conform to a protocol? If the latter - where are the useful, commonly used
> categories?
> Are there any plans to do anything in this area - or is it just a lump it
> scenario?
> Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20190228/27b53409/attachment.html>

More information about the Pharo-users mailing list