El mié, 08-09-2010 a las 19:27 -0700, Andreas Raab escribió: It is amazing how square-minded you are. All this diatribe was nothing but to defend the current state of the code you write.
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).
So now overrides are encouraged?
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.
Well then lets rename withBlanksTrimmed to, lets say, windowsWithBlankTrimmed, or maybe lispWithBlankTrimmed, or better yet, asdfAsdfASDF. The name must be right, no matter what you personally think.
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. ].
Maybe in practice happens. That is not a excuse to put the burden in the environment and let the software that relies in wrong code remain unfixed. If some package hits the error, the right thing is to fix the package, not to put trash in the environment just in case. This promotes mean software
The problem with these uses is that it's quite easy to forget some asString, or #printString (for example, if you generally had expected foo to be a string but in the impossible condition it's actually nil) and when you hit the condition your logging screws up and instead of getting informed about the impossible condition the program quits due to the error. In fact, I'm willing to bet that there's at least one bug in Pharo and/or Seaside which is the result of erroneous string concatenation of this kind. It's just very easy to get wrong.
Idem. If that is the case, then Seaside must be corrected.
The other relevant bit about this change is that it's entirely type-safe. I.e., the return type does not depend on the argument, the return type is always a string. That means that the change does *not* introduce failures down the road due to type violations. It *does* mean that if you have a bug in your code you might print "a SomethingOrOther" when you didn't mean to, but unless you're the kind of person who believes that a program that doesn't raise an error must be obviously correct, this makes little difference. The only difference it makes is that your program will not abort when the *intention* is so utterly obvious.
Wrong, I prefer it abort loudly so I now that there is something wrong in the package and I can fix it, not hide it because the environment somehow worked around it.
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.
So your experience is real data to back up your claims but others isn't. BS!
Last but not least, programming is about efficiency.
Umm, wasn't Smalltalk about intention-reveling code. Wasn't adviced everytime that premature optimization is evil. Since when Smalltalk was about efficiency. Isn't C programming.
Why would you waste your time in typing 'The result is: ', x printString" when you could just type "'The result is: ', x" and spare the time to write all the extra characters? Do you realize how much time you've wasted sprinkling all those #printString and #asString around WebClient?
So, if you are tagging the effort that they put in modifying WebClient as wasted time, then I think there is nothing to discuss between the possible contributors and you. This is not a dialog or a discussion is an intransigent monologe. -- Miguel Cobá http://miguel.leugim.com.mx