As reported elsewhere:
Begin forwarded message:
From: Florin Mateoc <florin.mateoc@gmail.com> Subject: [squeak-dev] #adaptToNumber:andSend: in String Date: 24 May 2015 22:04:21 CEST To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org> Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Hi all,
Does anybody know why was the arithmetic protocol added to strings?
Evaluating '2' > 1 raises a DNU Evaluating 1 < '2' answers true. Even worse, 1 < '2bla' answers true as well.
This (the successful part) happens because of the implementation mentioned in the subject (plus numeric parser's behavior). That implementation was not part of the original protocol, as written by Dan Ingalls in 1998. It seems to have been added by Yoshiki in 2004. Was this done to address something in particular? To me it seems inconsistent, as in the above examples. There are other inconsistencies as well: the arithmetic operators mostly work - they were implemented in String by Yoshiki in 2004 as well, but e.g. 1s + '2' fails ('2' + 1s succeeds). And there is further funny behavior:
'2' + 1 evaluates to 3 '2' + '1' evaluates to '3' '2foo' + '1bar' evaluates to '3'
Presumably the failures could be made to work as well, but is this desirable? To me this seems as bad and arbitrary as Javascript's automatic conversions (there both comparisons mentioned above succeed, but 1 + '2' evaluates to '12' and '2' + 1 evaluates to '21', whereas 1 - '2' evaluates to -1 and '2' - 1 evaluates to 1. Just beautiful!).
Best, Florin
All this is just terrible, I knew there was some of this stuff in Pharo, but this is way worse than I expected it to be. And who uses this anyway ? Here are the mentioned expressions for easy copy/paste: '2' > 1. 1 < '2'. 1s + '2'. '2' + 1s. '2' + 1. '2' + '1'. '2foo' + '1bar'. Sven
On 25 May 2015, at 11:08, Sven Van Caekenberghe <sven@stfx.eu> wrote:
As reported elsewhere:
Begin forwarded message:
From: Florin Mateoc <florin.mateoc@gmail.com> Subject: [squeak-dev] #adaptToNumber:andSend: in String Date: 24 May 2015 22:04:21 CEST To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org> Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Hi all,
Does anybody know why was the arithmetic protocol added to strings?
Evaluating '2' > 1 raises a DNU Evaluating 1 < '2' answers true. Even worse, 1 < '2bla' answers true as well.
This (the successful part) happens because of the implementation mentioned in the subject (plus numeric parser's behavior). That implementation was not part of the original protocol, as written by Dan Ingalls in 1998. It seems to have been added by Yoshiki in 2004. Was this done to address something in particular? To me it seems inconsistent, as in the above examples. There are other inconsistencies as well: the arithmetic operators mostly work - they were implemented in String by Yoshiki in 2004 as well, but e.g. 1s + '2' fails ('2' + 1s succeeds). And there is further funny behavior:
'2' + 1 evaluates to 3 '2' + '1' evaluates to '3' '2foo' + '1bar' evaluates to '3'
Presumably the failures could be made to work as well, but is this desirable? To me this seems as bad and arbitrary as Javascript's automatic conversions (there both comparisons mentioned above succeed, but 1 + '2' evaluates to '12' and '2' + 1 evaluates to '21', whereas 1 - '2' evaluates to -1 and '2' - 1 evaluates to 1. Just beautiful!).
Best, Florin
All this is just terrible, I knew there was some of this stuff in Pharo, but this is way worse than I expected it to be.
We have a bug report about this since day 1⦠sadly it is a bit boring to work on, so nothing happened.
And who uses this anyway ?
Morphic, of course. Marcus
All this is just terrible, I knew there was some of this stuff in Pharo, but this is way worse than I expected it to be.
We have a bug report about this since day 1⦠sadly it is a bit boring to work on, so nothing happened.
https://pharo.fogbugz.com/f/cases/2906/Analyze-adaptToNumber-andSend <https://pharo.fogbugz.com/f/cases/2906/Analyze-adaptToNumber-andSend> It is now the oldest open issue. Sometimes I wish more people would help fixing thing reported on the issue trackerâ¦. Marcus
As you see guillermo and me worked on this.
All this is just terrible, I knew there was some of this stuff in Pharo, but this is way worse than I expected it to be.
We have a bug report about this since day 1⦠sadly it is a bit boring to work on, so nothing happened.
https://pharo.fogbugz.com/f/cases/2906/Analyze-adaptToNumber-andSend
It is now the oldest open issue.
Sometimes I wish more people would help fixing thing reported on the issue trackerâ¦.
Marcus
On 25 May 2015, at 11:31, Marcus Denker <marcus.denker@inria.fr> wrote:
All this is just terrible, I knew there was some of this stuff in Pharo, but this is way worse than I expected it to be.
We have a bug report about this since day 1⦠sadly it is a bit boring to work on, so nothing happened.
https://pharo.fogbugz.com/f/cases/2906/Analyze-adaptToNumber-andSend
It is now the oldest open issue.
That is both sad and funny at the same time ...
All this is just terrible, I knew there was some of this stuff in Pharo, but this is way worse than I expected it to be.
We have a bug report about this since day 1⦠sadly it is a bit boring to work on, so nothing happened.
And who uses this anyway ?
Morphic, of course.
Do you have an idea where? if you have a fix I would like to see how morphic gets broken because we should clean this and we will fix morphic.
Marcus
The problem is that while the intention was nice 5 + (1 to: 10) could make sense, its side effects are worse. Stef
Begin forwarded message:
From: Florin Mateoc <florin.mateoc@gmail.com> Subject: [squeak-dev] #adaptToNumber:andSend: in String Date: 24 May 2015 22:04:21 CEST To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org> Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Hi all,
Does anybody know why was the arithmetic protocol added to strings?
Evaluating '2' > 1 raises a DNU Evaluating 1 < '2' answers true. Even worse, 1 < '2bla' answers true as well.
This (the successful part) happens because of the implementation mentioned in the subject (plus numeric parser's behavior). That implementation was not part of the original protocol, as written by Dan Ingalls in 1998. It seems to have been added by Yoshiki in 2004. Was this done to address something in particular? To me it seems inconsistent, as in the above examples. There are other inconsistencies as well: the arithmetic operators mostly work - they were implemented in String by Yoshiki in 2004 as well, but e.g. 1s + '2' fails ('2' + 1s succeeds). And there is further funny behavior:
'2' + 1 evaluates to 3 '2' + '1' evaluates to '3' '2foo' + '1bar' evaluates to '3'
Presumably the failures could be made to work as well, but is this desirable? To me this seems as bad and arbitrary as Javascript's automatic conversions (there both comparisons mentioned above succeed, but 1 + '2' evaluates to '12' and '2' + 1 evaluates to '21', whereas 1 - '2' evaluates to -1 and '2' - 1 evaluates to 1. Just beautiful!).
Best, Florin All this is just terrible, I knew there was some of this stuff in Pharo, but this is way worse than I expected it to be. And who uses this anyway ?
Here are the mentioned expressions for easy copy/paste:
'2' > 1. 1 < '2'.
1s + '2'. '2' + 1s.
'2' + 1. '2' + '1'. '2foo' + '1bar'.
Sven
On 5/25/2015 6:02 AM, stepharo wrote:
The problem is that while the intention was nice 5 + (1 to: 10) could make sense, its side effects are worse.
Stef
I don't think there is anything wrong with your example, which is about vector operations and which I think make sense (I would have preferred if the result of the evaluation would have been an interval as well though). They are also part of the original protocol. I was only protesting the later addition of the arithmetic protocol to strings. It does not make sense to treat strings as vectors and there are no clear semantics for some other kind of string-specific arithmetic operations. Florin
2015-05-25 20:24 GMT+03:00 Florin Mateoc <fmateoc@gmail.com>:
I don't think there is anything wrong with your example, which is about vector operations and which I think make sense (I would have preferred if the result of the evaluation would have been an interval as well though). They are also part of the original protocol.
But there is not number intervals like "$a to: $c". And there is no place for #+ there
Hi florin I agree with you. If you have some cycles to propose a fix we would be delighted. Stef Le 25/5/15 19:24, Florin Mateoc a écrit :
On 5/25/2015 6:02 AM, stepharo wrote:
The problem is that while the intention was nice 5 + (1 to: 10) could make sense, its side effects are worse.
Stef
I don't think there is anything wrong with your example, which is about vector operations and which I think make sense (I would have preferred if the result of the evaluation would have been an interval as well though). They are also part of the original protocol.
I was only protesting the later addition of the arithmetic protocol to strings. It does not make sense to treat strings as vectors and there are no clear semantics for some other kind of string-specific arithmetic operations.
Florin
Hi Stef, I think this one's easy, especially for Pharo. Since apparently it was Etoys, not Morphic, that was or is using the strings and numbers mixed arithmetic, and Pharo does not care about Etoys, the arithmetic protocol (the operators plus the adaptTo...:andSend: methods) should simply be removed from String. While I did not perform any extensive testing, I did remove them in a Squeak (Morphic) image and nothing seemed to break. Even for Squeak, I think the solution should be the same and Etoys should be fixed to not use this particular hack. Florin On 5/26/2015 2:20 AM, stepharo wrote:
Hi florin
I agree with you. If you have some cycles to propose a fix we would be delighted.
Stef
Le 25/5/15 19:24, Florin Mateoc a écrit :
On 5/25/2015 6:02 AM, stepharo wrote:
The problem is that while the intention was nice 5 + (1 to: 10) could make sense, its side effects are worse.
Stef
I don't think there is anything wrong with your example, which is about vector operations and which I think make sense (I would have preferred if the result of the evaluation would have been an interval as well though). They are also part of the original protocol.
I was only protesting the later addition of the arithmetic protocol to strings. It does not make sense to treat strings as vectors and there are no clear semantics for some other kind of string-specific arithmetic operations.
Florin
On 26 May 2015, at 14:51, Florin Mateoc <fmateoc@gmail.com> wrote:
Hi Stef,
I think this one's easy, especially for Pharo. Since apparently it was Etoys, not Morphic, that was or is using the strings and numbers mixed arithmetic, and Pharo does not care about Etoys, the arithmetic protocol (the operators plus the adaptTo...:andSend: methods) should simply be removed from String. While I did not perform any extensive testing, I did remove them in a Squeak (Morphic) image and nothing seemed to break.
I committed a slice: https://pharo.fogbugz.com/f/cases/2906/Analyze-adaptToNumber-andSend <https://pharo.fogbugz.com/f/cases/2906/Analyze-adaptToNumber-andSend> Marcus
On 5/26/2015 9:38 AM, Marcus Denker wrote:
On 26 May 2015, at 14:51, Florin Mateoc <fmateoc@gmail.com <mailto:fmateoc@gmail.com>> wrote:
Hi Stef,
I think this one's easy, especially for Pharo. Since apparently it was Etoys, not Morphic, that was or is using the strings and numbers mixed arithmetic, and Pharo does not care about Etoys, the arithmetic protocol (the operators plus the adaptTo...:andSend: methods) should simply be removed from String. While I did not perform any extensive testing, I did remove them in a Squeak (Morphic) image and nothing seemed to break.
I committed a slice:
https://pharo.fogbugz.com/f/cases/2906/Analyze-adaptToNumber-andSend
Marcus
Hi Markus, Thank you. I forgot to mention, the non-String implementations of adaptToString:andSend: are part of the same bunch and they can now also go, nobody sends them anymore Florin
On 26 May 2015, at 15:51, Florin Mateoc <fmateoc@gmail.com> wrote:
On 5/26/2015 9:38 AM, Marcus Denker wrote:
On 26 May 2015, at 14:51, Florin Mateoc <fmateoc@gmail.com <mailto:fmateoc@gmail.com>> wrote:
Hi Stef,
I think this one's easy, especially for Pharo. Since apparently it was Etoys, not Morphic, that was or is using the strings and numbers mixed arithmetic, and Pharo does not care about Etoys, the arithmetic protocol (the operators plus the adaptTo...:andSend: methods) should simply be removed from String. While I did not perform any extensive testing, I did remove them in a Squeak (Morphic) image and nothing seemed to break.
I committed a slice:
https://pharo.fogbugz.com/f/cases/2906/Analyze-adaptToNumber-andSend <https://pharo.fogbugz.com/f/cases/2906/Analyze-adaptToNumber-andSend>
Marcus
Hi Markus,
Thank you. I forgot to mention, the non-String implementations of adaptToString:andSend: are part of the same bunch and they can now also go, nobody sends them anymore
Ah, yes. I have updated the fix. Marcus
participants (5)
-
Denis Kudriashov -
Florin Mateoc -
Marcus Denker -
stepharo -
Sven Van Caekenberghe