I forgot to mention that in order to be able to translate XPath to Smalltalk I added these methods to my Smalltalk: AbstractSequence>> afterSubCollection: aSequence [ifAbsent: exceptionBlock] "based on substring-after" beforeSubCollection: aSequence [ifAbsent: exceptionBlock] "based on substring-before" I'm not going to display the code, which is pretty simple, because there is a serious efficiency problem with these. (The Java equivalent, had there been one, would not have had this problem, but since I think Java 7 it would too.) Imagine that we have a string consisting of N instances of separators, and we want to split it into pieces. [s includesSubCollection: separator] whileTrue: [ self process: (s beforeSubCollection: separator). s := s afterSubCollection: separator]. s isEmpty ifFalse: [ self process: s]. Do I need to explain why this takes O(N**2) time? However, r := ReadStream on: s. [r atEnd] whileFalse: [ self process: (r upToAll: separator)]. is linear time (assuming an efficient #upToAll:). My previous remarks about boundary issues apply here as well, of course. My previous remarks about wanting to see the context do too. On Sun, 2 Jun 2019 at 00:43, Ben Coman <btc@openinworld.com> wrote:
On Sat, 1 Jun 2019 at 18: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 ?
Can your input be split into tokens using Stirng>>findTokens: and `ReadStream on: that`. Then you marker will be consumed by a single #next.
cheers -ben