On 26.09.2014, at 20:27, Max Leske <maxleske@gmail.com> wrote:


On 26.09.2014, at 18:44, Sven Van Caekenberghe <sven@stfx.eu> wrote:


On 26 Sep 2014, at 18:21, Eliot Miranda <eliot.miranda@gmail.com> wrote:



On Fri, Sep 26, 2014 at 6:20 AM, Max Leske <maxleske@gmail.com> wrote:

On 20.09.2014, at 03:02, Esteban A. Maringolo <emaringolo@gmail.com> wrote:

2014-09-19 20:59 GMT-03:00 Eliot Miranda <eliot.miranda@gmail.com>:


On Fri, Sep 19, 2014 at 1:19 AM, Max Leske <maxleske@gmail.com> wrote:

This issue was more of a discussion between Camillo and Sven. They never
reached a conclusion, so please take a look. I�ve compiled the transcript
below.

The issue isn�t easy to solve and maybe we can just close it as �not
important�.


+1.  But isn't the selector printString: broken?


The selector sounds broken to me too.

I always bring Dolphin to the discussion, but Dolphin streams had both
#print:/#display:

WriteStream>>#print: anObject
  anObject printOn: aStream.

WriteStream>>#display: anObject
  anObject displayOn: aStream.

But those are for printing/displaying the argument on the stream,
which is not exactly the same as sending #asString and then then
appending the result to receiver. So Eliot's #printAsString: seems to
be the most intention revealing selector for such task.

Ok, so how about adding WriteStream>>printAsString:? Implementation:

printAsString: anObject
       self nextPutAll: anObject asString

If you add this it also needs to be added to whatever the transcript streams are.  The two should have the same protocol for writing.  Right now there are a number of missing methods on the transcript side.

I still don't like it, we're just adding methods, making the API fatter, for what exactly ?

What is the difference between

 stream printAsString: foo

and

 stream << foo asString

None really. Actually I don�t quite see why #asString should ever be sent (except for during error handling maybe). I usually override #printOn: for displaying information about an object during development and use a specific implementation when I want to store an object on a stream. So I rarely need #asString in combination with streams.



?

Do we really need this ?

No, I guess not. It has worked fine so far. But since the discussion was opened I thought I�d push a little :)

So: anybody opposed to closing this issue?


Closed as �won�t fix".

Cheers,
Max


Sven