Why is #findString: in accessing?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Why is #findString: in accessing?

Tim Mackinnon
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
Reply | Threaded
Open this post in threaded view
|

Re: Why is #findString: in accessing?

Sven Van Caekenberghe-2
Tim,

It always takes effort to learn a new language/environment/library. You can't expect it to be the same to what you know, or for things to be where you expect them.

String is also one of the most overloaded classes in the system, it will never be clean.

Lots of things fall under 'accessing', that finding something is classified as such, does not really surprise me.

Did you know about the Finder 'by example search' ? Here is how to find your selector:


HTH,

Sven

On 25 Feb 2019, at 12:19, Tim Mackinnon <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Why is #findString: in accessing?

Tim Mackinnon
Hi Sven, thanks for kicking in - yes I do resort to that Finder (and I keep meaning to learn how to port that example search to spotter somehow) - however it only works for non-keyword selectors… (another one to investigate to see if it could potentially let you specify a parameter for its search).

I still wonder however if a category for ‘searching’ might be way more approachable - as accessing is far to broad on collection classes?

Tim

On 25 Feb 2019, at 11:40, Sven Van Caekenberghe <[hidden email]> wrote:

Tim,

It always takes effort to learn a new language/environment/library. You can't expect it to be the same to what you know, or for things to be where you expect them.

String is also one of the most overloaded classes in the system, it will never be clean.

Lots of things fall under 'accessing', that finding something is classified as such, does not really surprise me.

Did you know about the Finder 'by example search' ? Here is how to find your selector:

<Screenshot 2019-02-25 at 12.36.15.png>

HTH,

Sven

On 25 Feb 2019, at 12:19, Tim Mackinnon <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: Why is #findString: in accessing?

Richard O'Keefe
In reply to this post by Tim Mackinnon
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
#indexOfSubCollection:startingAt:[ifAbsent:]
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Why is #findString: in accessing?

K K Subbu


On 28/02/19 5:23 AM, Richard O'Keefe wrote:

> 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.)
>
Richard,

There is Browser>>#categorizeAllUncategorizedMethods that works this way
in Squeak but for uncategorized methods.

But then, a tag-set would be more useful than just single
categorization. It doesn't matter how accurate a category is, there will
always be someone who will find an equally justifiable reason for
putting a method into a different category ;-).

Is it possible to have a pragma or dummy method (say tags:) to list tags
that could be extracted to facilitate searches? It should not have any
runtime impact.

Regards .. Subbu

Reply | Threaded
Open this post in threaded view
|

Re: Why is #findString: in accessing?

Richard Sargent
Administrator
On Wed, Feb 27, 2019, 21:50 K K Subbu <[hidden email]> wrote:


On 28/02/19 5:23 AM, Richard O'Keefe wrote:

> 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.)
>
Richard,

There is Browser>>#categorizeAllUncategorizedMethods that works this way
in Squeak but for uncategorized methods.

But then, a tag-set would be more useful than just single
categorization. It doesn't matter how accurate a category is, there will
always be someone who will find an equally justifiable reason for
putting a method into a different category ;-).

Or you could model it correctly. Formally define how packages extend classes and allow an arbitrary number of categories for any method.

It's not you would be doing anything new. VA Smalltalk has been doing that for more and a quarter of a century.


Is it possible to have a pragma or dummy method (say tags:) to list tags
that could be extracted to facilitate searches? It should not have any
runtime impact.

Regards .. Subbu

Reply | Threaded
Open this post in threaded view
|

Re: Why is #findString: in accessing?

Richard O'Keefe


On Thu, 28 Feb 2019 at 18:59, Richard Sargent <[hidden email]> wrote:

It's not you would be doing anything new. VA Smalltalk has been doing that for more and a quarter of a century.

I have Squeak, Pharo, ST/X, GST, VW, VAST, Dolphin,
and even Strongtalk.
I found the development UI of VAST hard to use for several
reasons.  It is useful to know which package a method belongs
to sometimes, but not having semantic categories is a pain.


Reply | Threaded
Open this post in threaded view
|

Re: Why is #findString: in accessing?

Richard Sargent
Administrator
On Thu, Feb 28, 2019, 03:49 Richard O'Keefe <[hidden email]> wrote:


On Thu, 28 Feb 2019 at 18:59, Richard Sargent <[hidden email]> wrote:

It's not you would be doing anything new. VA Smalltalk has been doing that for more and a quarter of a century.

I have Squeak, Pharo, ST/X, GST, VW, VAST, Dolphin,
and even Strongtalk.
I found the development UI of VAST hard to use for several
reasons.  It is useful to know which package a method belongs
to sometimes, but not having semantic categories is a pain.

Can you elaborate on that point? I don't understand what you mean by semantic categories. And that makes it hard for me to understand the "not having" point.