A few more comments below; I'm not seeing the things you describe when testing in my image...
>> >> | id | >> id := LargePositiveInteger. >> 1 to: (16777215 + 50) do: [:each | >> id := id digitAdd: 1]. >> id. >> >> Given the comment it should overflow and the value be 50? This is not what >> the result is. So shall the truncation be added again or at least the >> comment be updated? The code will go from LargePositiveInteger to >> SmallInteger when overflowing from three to four bytes On which VM does it overflow to SmallInteger? I've never seen this, on the one I tested the expression in last mail, the "overflowing" digitAdd: returned a 4-byte LargePositiveInteger. >> but luckily >> >>>> #value >> ... >> replaceFrom: 1 to: 3 with: self class counterNext startingAt: 1 >> >> will even work when counterNext returns a SmallInteger. But given the old >> code and the comment in the new code this is does not seem to function as >> intended? >> Are you sure? On my VM, (ByteArray new: 3) replaceFrom: 1 to: 3 with: 16r1FFFFFF startingAt: 1 gives an "Instances of SmallInteger are not indexable" error... >> >> >> PS: The other part is that >>#newCounter doesn't seem to be ever executed. >> On first load >>#initialize will call >>#reset and on >>#shutDown: calls >> reset. So the code to "randomize" the initial counter doesn't seem to work. What? OID class >> #initialize adds the class to the shutdown list, so it *should* call shutDown: whenever the image is saved&quit. newCounter should then be called on first request after startup, since machineIdentifier is set to nil by reset. Cheers, Henry
signature.asc
Description: Message signed with OpenPGP using GPGMail
