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.nice@gmail.com> wrote:

2017-04-08 6:38 GMT+02:00 Ben Coman <btc@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)?