Den 08.11.2010 04:28, skrev Andreas Raab:
On 11/7/2010 1:38 PM, Henrik Sperre Johansen wrote:
IMO the obvious solution is to fix the problem where it orginated, in the Pharo image.
Reverting would reintroduce getting invalid results from the plugin, without any workaround. Not really an option.
You could just fix the problem, you know :-) Seriously, if there's a bug in the plugin, perhaps we should fix that problem? After which reverting the method is obviously the correct solution for this problem.
Cheers,
- Andreas
Oh absolutely, you just have to add the disclaimer: "Only run this image with a VM built from VMMaker with an image version newer than XY (Pharo) or ZI (Squeak). :-) (Which is what I meant with reproducibility issues, btw)
As for why I haven't just fixed it: For it to work correctly, I can't really see any way around choosing different paths based on whether either/both of the arguments are WideStrings. I was of the assumption you could only do type annotations in code primitives written this way, not lookup classes etc. I'd be delighted if that were incorrect, or there's some other way to differentiate the two my limited VM knowledge does not cover.
I imagine the match table part would have to be rewritten as well if one wanted to use it for Unicode-aware caseinsensitive search, there are 1050 1:1 upper/lowercase mappings in Unicode, last one at codepoint 66639. So in that case there's more work than one would expect, and a good solution would not be backwards-compatible either way.
Cheers, Henry