EsString>>#subStrings: changed to be ANSI-compliant and portable
Reason for the change
The implementation of EsString>>#subStrings: did not conform to the definition of this method in the ANSI Smalltalk Standard (which states that the method should take a collection of separator characters as its argument).
In addition, its behavior in some situations (leading, trailing, and multiple adjacent separator characters) did not match the behavior of EsString>>#subStrings nor did it match the behavior of the #subStrings: method on other Smalltalk platforms (which makes porting code from other platforms to VA Smalltalk difficult).
EsString>>#subStrings: parsed strings as follows:
'@b' subStrings: $@ answered #('' 'b')
'@' subStrings: $@ answered #('' '')
'abc' subStrings: $@ answered #('abc')
'' subStrings: $@ answered #('')
Change
Three changes have been made:
EsString>>#subStrings: will now accept either a single character separator or a collection of character separators as its argument. It will parse strings as follows:
'abc@def:123' subStrings: $@ answers #('abc' 'def:123')
'abc@def:123' subStrings: '@' answers #('abc' 'def:123')
'abc@def:123' subStrings: '@:' answers #('abc' 'def' '123')
EsString>>#subStrings: will now ignore leading separators, trailing separators, and separators which are immediately adjacent to other separators. It will parse strings as follows:
'@b' subStrings: $@ answers #('b')
'@' subStrings: $@ answers #()
'abc' subStrings: $@ answers #('abc')
'' subStrings: $@ answers #()
EsString>>#allSubStrings: has been added. It behaves the same way that EsString>>#subStrings: did in previous releases.
Action required
The change to EsString>>#subStrings: which makes it ignore leading separators, trailing separators, and separators which are immediately adjacent to other separators may require changes to user code (depending on the exact expectations of senders of the message).
Here are several examples of code along with descriptions of how they should be changed:
1. Splitting a directory path into its component parts:
('/home/user/bin/command' subStrings: $/) reject: [:string | string = ''].
2. While it is no longer necessary to scan the results of applying #subStrings: to the path in order to remove empty strings from the result, it causes no harm and does not need to be modified.Splitting a directory into its component parts and referencing a component part by its index in the results:
('/home/user/bin/command' subStrings: $/) at: 2.
Since #subStrings: no longer answers an empty string for a leading separator character, this code must be modified. It can be changed in at least 2 different ways to achieve the desired result:
('/home/user/bin/command' subStrings: $/) at: 1.
('/home/user/bin/command' allSubStrings: $/) at: 2.
3. Splitting an XLFD font name into its component parts:
('-microsoft-system-bold-r-normal--16-100-120-120-p-90-iso8859-1'
subStrings: $-) size = 15.
Notice that an XLFD font name has a fixed number of component parts (15) and can have null elements (look just after normal), so it is not sufficient simply to change the code to test for a size of 14. Rather, the code must be changed to use #allSubStrings: so that 15 component parts are still created.
This change may also affect third-party tools, such as HP WinRunner (an automated functional GUI testing tool), also. If you use such a tool, you should contact the tool vendor to determine whether the tool needs to be updated.
Last modified date: 06/19/2020