On Mon, 8 Nov 2010, David T. Lewis wrote:
snip
But I think that Andreas is asking another question: What was the original motivation for renaming the method? And based on that, is there something that needs to be fixed in the primitive itself so that this will not be an issue? I don't really know the background on this myself, but it looks like there was a problem related to passing a WideString as a parameter to ByteString>>findSubstring:in:startingAt:matchTable:, and that the workaround in Pharo was to put an #isWideString check into #findSubstring:in:startingAt:matchTable: (which of course completely trashed the translation of #findSubstring:in:startingAt:matchTable: when translating to C).
The problem is that the method expects ByteStrings as arguments, but it won't fail if one of them is a WideString. Instead it returns wrong results. Here's an example (in Squeak):
ByteString new findSubstring: 'b' in: 'abc' asWideString startingAt: 1 matchTable: ((0 to: 255) as: ByteArray). "===> 0"
The result is 0, while it should be 2. The problem is worked around in Squeak by making sure that the primitive is not used in this case.
'abc' asWideString findString: 'b' startingAt: 1 caseSensitive: true. "===> 2"
Though a naive user can still use the method as shown here.
Levente
The #isWideString check has a bad smell and suggests that there might be something that needs fixing in the primitive, after which the method could be reverted and everyone would be happy.
Unfortunately I am a modestly educated English speaker, so I am largely guessing as to the background on this issue ;)
Dave