On 9/9/2010 3:34 AM, Stéphane Ducasse wrote:
For string concatenation on the other hand, we're basically talking about dispersing a whole load of FUD about all the things that "may" go wrong. Fact is, nothing actually *does* go wrong with the change, but the change does fix situations that are *very* difficult to handle otherwise. One of the unfortunate realities of string concatenation is that it's very often used around error messages and logging, often in corner cases that aren't well tested, like:
<some impossible condition> ifTrue:[ self log: 'Found impossible condition: ', foo. ].
I do not buy this argument. We should fix the code and not break the libraries.
Yes, that is the usual FUD. Can you clarify how that change breaks any libraries, where and when exactly? Because it doesn't.
Your argument is bogus.
Which one? I made about five different arguments from that this change doesn't break anything, over it preserving the type semantics, that string concatenation often occurs in less tested code, that it is error-prone for no good reason, up until the efficiency argument. Or is it simply "I don't like this guy so matter what he says I will not listen"?
We do not want such kind of extensions that opens the door to really sloppy code.
And that would be sloppy code because ... ? It's more efficient to write it that way? Is that your measure of sloppyness? If not how do you distinguish "sloppy" code from other perfectly well accepted patterns like the type coercions happening in arithmetic? You *could* write "4 asFloat + 3.0" instead of "4 + 3.0" you know.
Then we should avoid overrides as much as possible.
I wholeheartedly agree but did you actually follow the Grease discussion? The problem of not being able to remove methods after they have been added to the base is quite real. The only way to address this problem currently is by using overrides. Cheers, - Andreas