but I guess that the printOn: method should still be working because we can invoke it instead of creating a new stream. I mean as a developer I do not know that printString is not creating a stream so normally I should use printOn: especially from other printOn: method to avoid the creation of spurious streams. Now this printstring method is just good to printString and asString (if it invokes it). May be smallInteger>>printOn: call it too if it does not I have the impression that it should.
On Sat, Apr 8, 2017 at 1:41 PM, Nicolas Cellier < nicolas.cellier.aka.n...@gmail.com> wrote: > > > 2017-04-08 6:38 GMT+02:00 Ben Coman <b...@openinworld.com>: > >> I was going to slip this example into the welcome help, >> >> 1 printString [debugIt] >> >> and I'm confronted by SmallInteger>>printString >> >> printString >> "Highly optimized version for base 10 >> and that we know it is a SmallInteger." >> | integer next result len | >> self = 0 ifTrue: [^'0']. >> self < 0 ifTrue: [^'-', self negated printString]. >> len := self decimalDigitLength. >> result := String new: len. >> integer := self. >> len to: 1 by: -1 do: [:i | >> next := integer // 10. >> result byteAt: i put: 48 + (integer - (next * 10)). >> integer := next]. >> ^result >> >> >> and I gather from other discussions this should(?) belong in >> SmallInteger>>printOn: >> Or is there a large benefit to avoiding the #printStringLimitedTo: >> machinery ? >> >> cheers -ben >> > > It should be printOn: generally, except that printOn: requires creating a > Stream, and requires passing thru Stream indirection for writing into the > target String. > > As the comment tells, the sole reason for this implementation is "Highly > optimized version". So consider that it's an exception to the rules. Maybe > this kind of decision could be periodically re-examined in the light of > performance measurements (I'm thinking of Sista)? >
