String>>#adaptToNumber:andSend:
Locked
String>>#adaptToNumber:andSend:
 
|
As reported elsewhere:
> Begin forwarded message: > > From: Florin Mateoc <[hidden email]> > Subject: [squeak-dev] #adaptToNumber:andSend: in String > Date: 24 May 2015 22:04:21 CEST > To: The general-purpose Squeak developers list <[hidden email]> > Reply-To: The general-purpose Squeak developers list <[hidden email]> > > 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 |
Re: String>>#adaptToNumber:andSend:
|
|
> On 25 May 2015, at 11:08, Sven Van Caekenberghe <[hidden email]> wrote: > > As reported elsewhere: > >> Begin forwarded message: >> >> From: Florin Mateoc <[hidden email]> >> Subject: [squeak-dev] #adaptToNumber:andSend: in String >> Date: 24 May 2015 22:04:21 CEST >> To: The general-purpose Squeak developers list <[hidden email]> >> Reply-To: The general-purpose Squeak developers list <[hidden email]> >> >> 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 |
Re: String>>#adaptToNumber:andSend:
|
|
It is now the oldest open issue. Sometimes I wish more people would help fixing thing reported on the issue tracker…. Marcus |
|
|
In reply to this post by Marcus Denker-4
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 > > > |
|
|
In reply to this post by Marcus Denker-4
As you see guillermo and me worked on this.
|
|
|
In reply to this post by Sven Van Caekenberghe-2
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 <[hidden email]> >> Subject: [squeak-dev] #adaptToNumber:andSend: in String >> Date: 24 May 2015 22:04:21 CEST >> To: The general-purpose Squeak developers list <[hidden email]> >> Reply-To: The general-purpose Squeak developers list <[hidden email]> >> >> 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 > > |
Re: String>>#adaptToNumber:andSend:
|
|
In reply to this post by Marcus Denker-4
> On 25 May 2015, at 11:31, Marcus Denker <[hidden email]> 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 ... |
Re: String>>#adaptToNumber:andSend:
|
|
In reply to this post by stepharo
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 |
Re: String>>#adaptToNumber:andSend:
|
|
2015-05-25 20:24 GMT+03:00 Florin Mateoc <[hidden email]>:
But there is not number intervals like "$a to: $c". And there is no place for #+ there |
|
|
In reply to this post by Florin Mateoc
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 > > > |
Re: String>>#adaptToNumber:andSend:
|
|
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 >> >> |
Re: String>>#adaptToNumber:andSend:
|
|
I committed a slice: Marcus
|
Re: String>>#adaptToNumber:andSend:
|
|
On 5/26/2015 9:38 AM, Marcus Denker
wrote:
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 |
Re: String>>#adaptToNumber:andSend:
|
|
Ah, yes. I have updated the fix. Marcus |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |