Why add an alias ? The API is too wide as it is already. Note that most current implementations of #upToAll: already use words like match, so #match: is not that crazy.
Yes it should be possible to talk about naming, but just adding aliases, no. My opinion, of course. > On 2 Jun 2019, at 04:33, Richard O'Keefe <[email protected]> wrote: > > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >
