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 ther
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 ,
return true leaving the position where? Otherw
On Sat, 1 Jun 2019 at 18:01, Tim Mackinnon 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:
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
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
Classic - I went to implement #skipUpToAll: and its called #match: in Pharo…. I
struggle with some of the naming of string and stream methods in
pharo/smalltalk and the protocols are often not quite what I expect either
(altough in this case, match is “positioning” which is more in line with my
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 wrote:
> Interesting
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:
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
The issue is that #skipToAll: is the de facto standard name for the
operation EXCEPT in Squeak and Pharo. It's not that an alias should
be added. What should *really* be done is that #match: should be
*renamed* to #skipToAll:. This will
- improve compatibility
- reduce confusion
- improve nav
To each his own opinion, #match: is not that bad a name, IMHO.
There is much more bloat than the mixing of reading and writing.
The concept of being positionable is bad too: it makes no sense for network and
other non-collection backed streams.
There is also all the binary, encoding and convert
Would it be really bad to use the deprecation feature in Pharo to gently
migrate to a more common name in stream? There are 101 senders of match: (in my
P7 image - presumably some of them my usage), and a lot of them actually
referring to string regex match:. Its big but not immense.
#match: no
12 matches
Mail list logo
