Maybe his question is (also) why the automatic refactoring did it wrong, the rules warned about the wrong use of #printString, suggested a fix, but the solution is still using #printString, hence the same problem.
> On 25 Dec 2020, at 16:20, Stéphane Ducasse <stephane.duca...@inria.fr> wrote: > > Hi > > this warning is just that printOn: is working on a stream > > and when we do > > printOn: aStream > > aStream nextPutAll: x printString > > printString creates yeat another stream then ask the contents and passes it > to the first one > > > printOn: aStream > > x printOn: aStream > > is faster and cleaner in that case. > > >> On 24 Dec 2020, at 18:32, g_patrickb--- via Pharo-users >> <pharo-users@lists.pharo.org> wrote: >> >> I started working through PBE8, and in section 3.13 there is a method: >> >> Counter >> printOn: aStream >> >> super printOn: aStream. >> >> aStream nextPutAll: ' with value: ', count printString. >> >> But it returns two warnings: >> >> [printString] No printString inside printOn >> >> Use cascaded nextPutAll:’s instead of #, in #nextPutAll: >> >> >> >> It has the option to automatically resolve the cascaded nextPutAll: which >> results in: >> >> printOn: aStream >> >> super printOn: aStream. >> >> aStream >> >> nextPutAll: ' with value: '; >> >> nextPutAll: count printString >> >> >> >> But it still has the warning about printString. >> > > -------------------------------------------- > Stéphane Ducasse > http://stephane.ducasse.free.fr / http://www.pharo.org > 03 59 35 87 52 > Assistant: Aurore Dalle > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, Bât.A, Park Plaza > Villeneuve d'Ascq 59650 > France >