On 08.09.2010 08:35, Igor Stasenko wrote:

On 7 September 2010 21:15, Philippe Marschall <kustos@gmx.net> wrote:

...

On 07.09.2010 09:03, Andreas Raab wrote:

...

Hi -

After careful consideration I've decided to put WebClient under the MIT license, and updated the repository at http://www.squeaksource.com/WebClient.html to reflect the license change.

If you're curious why I'm making the change, the answer is really that the code isn't all that unique and even though I'm not done with it it's good enough to be released and by now I simply get more benefits from it being thoroughly tested by as many people as possible. That and the (to me surprising) amount of interest that WebClient has received in combination with the (to me disturbing) lack of due diligence that many users of WebClient apparently have. I think we can all take away a lesson from this little incident that even if you find some random code on the net it doesn't mean it's up for grabs.

Also, if I may be so bold, let me propose the "2 step process to eternal license happiness". It's really simple:

[ ] Did we check the license of the package? [ ] Did we contact the author of the package?

If you check off the above two steps whenever you're about to use some third-party code, I think you'll find that situations like the one we've encountered here are virtually impossible. Attach the steps to the bug tracker if you must, but follow them.

Since you know how to verify the license status on your own, let me add the second step of the process and once more repeat that I would rather keep WebClient an externally loadable package. If at all possible I urge you to look at what has been done with HTTPSocket in Squeak and adopt a similar approach; that is provide a minimal internal HTTP interface and allow third-party libraries (WebClient or other) to hook into this interface. There is really no need to have everything tied together at the hip; HTTPSocket is a reasonable facade for HTTP requests in the kernel.

Regarding write access to the WebClient repository, I'm not a fan of making repos world-writable (this is really a sign of abandonware) but due to the license I'm fine with granting Sven and Philippe write access if they want it (drop me a note if you do).

Did you change your position towards #squeakToUtf8 and string concatenation (I didn't follow the entire previous thread)? Otherwise it would probably make more sense if I continue sending patches.

Now don't get me wrong, you're of course allowed to write code whichever way you see fit and reject anything that doesn't follow this. But the same goes for me. And for me it's important that code loads without any overrides. So I'm probably going to set up a WebClientPharo or WebClientPhilippe or something repository.

How about extra package in same repository (WebClient)?

I believe I just addressed that in the previous paragraph. Cheers Philippe

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

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

On 09.09.2010 04:27, 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,

That's fine.

but let's discuss this.

Personal coding styles are a matter of taste, no way we ever reach a consensus (the discussion that will go nowhere has already started).

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).

We need to fix that, thanks for pointing that out.

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.

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. ].

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.

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.

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.

Last but not least, programming is about efficiency. 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?

Cheers Philippe

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

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).

may be we should change the semantics of unload with overriding (without *overrides*): restore the hidden method that a new load can be do. Stef

Hey guys, did I miss something and Andreas is reading the pharo mailing list? If not than he is not included in cc: like Phillipe is. my 2 cents, Norbert On 09.09.2010, at 18:18, Stéphane Ducasse wrote:

BTW andreas I was reading your changes in squeak about fileList -> FileServices and I noticed that there is a bug there is one method missing suffixOf: in FileServices and I sent a notification in squeak-dev so may be you see it. I did not have the time to produce a fix but this is an easy one.

Stef

On Sep 9, 2010, at 4:27 AM, 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.

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. ].

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.

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.

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.

Last but not least, programming is about efficiency. 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?

Cheers, - Andreas

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project