If you want to move around in strings, you might want to use a ReadStream. In some Smalltalk systems there is a method called #skipToAll:. Here's how mine starts out: skipToAll: aSequence "If the remaining elements can be parsed as <a><aSequence><b>, return true leaving the position where? Otherwise return false. GNU Smalltalk, Dolphin, and VisualAge: leave the position after <aSequence>, consistent with #upToAll:, and implementable in this class. (GST uses the KMP algorithm.) VisualWorks and ST/X: leave the position before <aSequence>, inconsistent with #upToAll:, and only implementable for positionable streams. Squeak 5.2 and Pharo 6.0: not provided. I cannot be compatible with everything. The semantics of #skipToAll: should obviously match #upToAll:, so I'll fit in with GNU, Dolphin, and VisualAge Smalltalk. " So (myReadStream skipToAll: 'marker') ifTrue: [loc := myReadStream position] ifFalse: [alternative code]. HOWEVER, I have a bad feeling about this. The entire approach, as with much concerning strings in a Unicode age, seems fraught with peril. Consider input = 'the need for vigilance is never-ending' marker = 'end' Should the marker be found or not? input = '.... Si<floating acute accent> ...' marker = 'Si' Should the marker be found or not? My code is NOT sensitive to these issues. I would like to say that it was because I was writing a compatibility method, so my code was compatibly broken, but to be honest, I was stupid and forgot to think it through. I would think that there would need to be an '... asTokens: aBoolean' variant that checks that a match - is not followed by floating diacriticals - is not preceded by an alphanumeric if the target begins with one - is not followed by an alphanumeric if the target ends with one. My own preference is to write a lexical analyser for the mini-language I'm using, and NOT try to hack at it using general-purpose string methods. Perhaps you can tell us more about the context? What is the application- level task you are trying to solve? On Sat, 1 Jun 2019 at 22:01, Tim Mackinnon <tim@testit.works> wrote:
Maybe this is a dumb question - and often Iâm surprised when asking these, but why is there no way to âfind afterâ a string.
I find it rather boring to try and parse a string, after a known marker - thus: (loc := aString findString: âmarkerâ) > 0 ifTrue: [ loc := loc + âmarkerâ size ].
Is there a better way? This whole pattern seems very old and clunky and not smalltalk like?
Couldnât we have: findAfter: aString ifAbsent: aBlock ?
Or is there a whole better pattern for string searching that Iâm missing ?
Tim