WebClient License Update

> 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).
>
> Cheers,
>  - Andreas
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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).
>
> Cheers,
>  - Andreas
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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).
>
> Cheers,
>  - Andreas
>

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

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

> On 7 September 2010 21:15, Philippe Marschall <[hidden email]> 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)?

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

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

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

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

> 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?

> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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