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