On 9/9/2010 1:15 AM, Henrik Johansen wrote:
On Sep 9, 2010, at 4:27 50AM, Andreas Raab wrote:
Phillipe wrote:
Did you change your position towards #squeakToUtf8 and string concatenation (I didn't follow the entire previous thread)?
Implicitly yes, but let's discuss this. You're saying you want WebClient "without overrides" but is this really what you mean? The only reason these methods are marked overrides is so that they don't kill your system if the methods themselves get added to the system at some point. For example, Grease currently adds extension methods for Collection>>sorted but these methods are already in Squeak and while nothing harmful happens if you load Grease, unloading it will destroy several methods. As a consequence it is vastly advantageous to mark methods as overrides if they have even the slightest possibility to conflict (but of course if you'd rather have them straightforward extensions, I have no problems with that).
As for integrating the changes itself, I think that we're talking two very different issues here. I suspect that the only objection to #squeakToUtf8 and #utf8ToSqueak is that they have "Squeak" in their name. I don't think you'd have any objection if they would've been called #utf8Encoded and #utf8Decoded. Which, honestly, is a childish attitude from my point of view.
Yeesh. I can only speak for myself, but my objection to the methods is more that I don't think knowing how to change its contents to a specific encoding should be the responsibility of the String class. Yes, there are plenty of other comparable delegations of responsibility, but in this case it is easily avoided. Sure though, it's a bit faster in some cases than the alternatives using convertToWithConverter:, or convertToEncoding: (at least with a symbol -> converter cache added), but with the general improvements to UTF8TextConverter the speedup is no longer measured in the orders of magnitudes, where it might feel worth it (to me).
Which isn't really the argument. The utf8 encoding and decoding methods are by far the most commonly used conversion methods. They are similar to methods such as #zipped/#unzipped, or #base64Encoded/#base64Decoded. I actually have some code that literally uses: data := aString squeakToUtf8 zipped base64Encoded. Compare that with the (exactly) equivalent version that doesn't have the utility methods: (Base64MimeConverter mimeEncode: (((GZipWriteStream on: (RWBinaryOrTextStream on: String new)) nextPutAll: (aString convertToWithConverter: UTF8TextConverter new); close; encodedStream) contents) readStream) contents Thus, the basic claim here is that it's worthwhile to have shorthand methods for conversion to/from utf8 because it's so prevalent. As for why it's called squeakToUtf8 and utf8ToSqueak, that's simply because there's a family of conversion methods in String which use the squeakToXXX/xxxToSqueak pattern (remnants of which you can still find in Pharo). These methods got first introduced around Squeak 3.8 to deal with various issues during m17n integration and have been in Squeak ever since.
Put differently, the change adds nothing but robustness to the system. There is really no data to back up the FUD about all the changes that "may" go wrong, but from my experience there is ample evidence to show that logging and error handling involving string concatenation is highly susceptible to this kind of problem and generally not very well tested and difficult to QA. And the major use of string concatenation is right in these areas.
While I see some value in your arguments, in addition to Pharo, at least the VW, GST and ST-X dialects, plus the ANSI standard, do not allow it. IE, if you want to write your code the least bit portable, you include the ugly as/printString sends.
Unless you convince people to change things. Would make a fine addition to Grease, too :-) Cheers, - Andreas