[Bug][wrokaround]Character>>asciiValue

Torge Husfeldt thu at informatik.uni-kiel.de
Fri Apr 5 11:10:44 UTC 2002


Hi Squeakers
I just noticed that there are 120 senders of asciiValue and i think more
than 90% of 'em use it with #at:.
That means all of them have to work around the problem that asciiValues
range from 0..255 and Squeak Colelction usually from 1...(I know one can
use integer keyed dictionaries but that would be overkill)
Some of 'em don't, though like Scanner>>scanToken, Scanner>>xBinary.
This can lead to problems if you have zero valued characters in some
Source code stream.
My workaround was to provide a method like that:
<CSOTD>
Character>>asciiValueNonZero
	"like asciiValue, just in the Squeak-friendly range 1..256"
	"bitAnd: 255 stands for mod 256 but is supposed to be faster..."
	^((value + 255) bitAnd: 255) + 1
</CSOTD>
and use it in the appropriate places.
Now with the do once and do it right mentality some brave soul (lloks
like that would be me, but i'd rather not;) should look through all of
these 120 senders and decide if they are better of with using the
nonZero version than the +-1 thing they do right now (or don't - like i
mentioned). We could then switch the logic and provide a
Character>>zeroBasedAsciiValue or something similar for the (rare) cases
where this is needed. I regard way it is right now as a severe case of
source code uglification along with some degree of brain twist (so the
array is translated by one so for when i ask for the index of
myCharacter i have to add 1 -- or substract?).

Squeak on,
Torge
P.S.:I would have provided a cs, but only if and when this was a
finished issue



More information about the Squeak-dev mailing list