Anybody have any insight on why String>>asInteger doesn't seem to think negative integers are really integers? It is "fixable" with #asNumber, as follows:
'-1' asInteger --> 1 '-1' asNumber asInteger --> -1
Shouldn't String>>asInteger be smarter than that, and not ignore negative integers?
This behavior is verified on 3.5, 3.6, and 3.7. So, it's been around for awhile.
Nevin
Nevin Pratt wrote:
Anybody have any insight on why String>>asInteger doesn't seem to think negative integers are really integers?
I reported this as a bug back in January but I didn't follow it up. There was a small thread on the subject. I don't have a BFAV handy to see if anything happened on it or if it is still open as a bug.
Sorry, cheers
Mike
Michael Roberts wrote:
Nevin Pratt wrote:
Anybody have any insight on why String>>asInteger doesn't seem to think negative integers are really integers?
I reported this as a bug back in January but I didn't follow it up. There was a small thread on the subject. I don't have a BFAV handy to see if anything happened on it or if it is still open as a bug.
Sorry, cheers
Mike
Ah, yes. Now I remember. I even responded to that thread. There was a bunch of discussion about various reimplementation possibilities, some of which involved raising exceptions, etc. I personally lean towards one of Doug's simple solutions, which I've copied below.
Nevin
From Doug Way, 1/21/04:
I agree that the naming here is bad enough to be considered a bug. The solution would appear to be to rename String>>asInteger to String>>asUnsignedInteger, and rename String>>asSignedInteger to String>>asInteger. (Or possibly keep asSignedInteger, but that seems like a bad idea.)
It looks like there are no senders of asUnsignedInteger in the alpha image. There are lots of senders of asInteger, but many of those are converting from other Number types. I'd guess that probably none of the senders rely on the signed behavior, but we'd just have to wait and see if any bugs showed up.
squeak-dev@lists.squeakfoundation.org