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 |
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: |
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
|
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. |
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 |
Administrator
|
On Wed, Feb 27, 2019, 21:50 K K Subbu <[hidden email]> wrote:
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.
|
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. |
Administrator
|
On Thu, Feb 28, 2019, 03:49 Richard O'Keefe <[hidden email]> wrote:
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. |
Free forum by Nabble | Edit this page |