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
>
