skipToAll: aCollection
"Set the receiver's position to just after the next occurrence of
aCollection
in the receiver's future values and answer true. If there is no such
occurrence, answer false. In either case, left the postion where
#upToAll:
would have left it."
^self match: aCollection
Sorry about the incomplete message.
#match: is such a bad name for this operation that the method comment has to
go to some trouble to explain that it is nothing like #match: for Strings.
On Sun, 2 Jun 2019 at 14:29, Richard O'Keefe <rao...@gmail.com> wrote:
> To get #skipToAll: in Pharo, add this to PositionableStream.
>
> skipToAll: aCollection
> "Set the receiver's to just after the next occcurrence of aCollection
> in the receiver's future values and answer true. If there is no such
>
>
> On Sun, 2 Jun 2019 at 07:50, Tim Mackinnon <tim@testit.works> wrote:
>
>> Interesting - there is no #skipToAll: in pharo, I wonder why not? It
>> sounds like what I was looking for - and I’m surprised its not there. There
>> is #skipTo: for an object (which sounds right, just not the string
>> equivalent).
>>
>> I’m not doing anything special, just want to take some lines from the end
>> of a class comment and use them in an exercism exercise - but its not
>> different than many applications - find some tag and use the text after it.
>> I”m kind of surprised its not in Pharo.
>>
>> Tim
>>
>>
>> On 1 Jun 2019, at 12:25, Richard O'Keefe <rao...@gmail.com> wrote:
>>
>> 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
>>>
>>
>>
