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 converting API that assumes a specific type of element, an assumption that is not always correct. Yes, Traits could help, but all this is a lot of work. And I feel like this is a lost battle: everybody keeps on asking to put his/her favourite methods back. > On 3 Jun 2019, at 00:20, Richard O'Keefe <[email protected]> wrote: > > 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 navigability > > At the moment, for example, it is much harder to discover the > consequences of renaming the #match: method than it should be > because not just people but the system itself confuses #match: > with #match:. > > The *real* API bloat in PositionableStream is that it covers > both positionable input streams (which can implement #skipToAll:) > and positionable output streams (which cannot), so that there > are way too many methods in the interface of a WriteStream that > cannot possibly work in any state of the receiver. > > With Trait support in Pharo, it is long past time that ReadStreams > (and files opened for input only) did not respondTo: #nextPut: and > that WriteStreams (and files opened for output only) did not > respondTo: #next. > > THAT bloat dwarfs a compatibility method. > > > On Mon, 3 Jun 2019 at 03:04, Sven Van Caekenberghe <[email protected]> wrote: > 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 > > > >
