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â. https://pharo.fogbugz.com/f/cases/11536/Add-Stream-printString ============ Camillo: This method should be added to avoid many asString sends. Example: stream nextPutAll: #('ABC') asString could be written as stream printString: #('ABC'). This is a common extension of the following pattern: stream nextPutAll: #('ABC') printString could be written as stream print: #('ABC'). ============ Sven: And what about #print: as implemented by Transcripts and SocketStreams ? It is shorter. Feels more familiar. ============ Camillo: #print: is already implement and doesn't solve the stream nextPutAll: foo asString case. Since you cannot simply write stream print: foo, since you get quotes added for Strings. Ok, I admit that with decent design you can avoid this, since it should almost never happen that you have a String or a non string object in the same variable, right? ============ Sven: Yeah, that String issue is a bit annoying sometimes. Indeed there is Stream>>#print: already. But look: ThreadSafeTranscript>>#print: anObject self nextPutAll: anObject asString how about that ? There is also #<< whose implementation is even weirder, but it is handy. The question remain: when do you want to mix Strings and other objects as arguments ? ============ Camillo: - #<< is basically a lazy combination of #nextPut: and #nextPutAll: - #print: should call #printOn: on the initial argument, which for strings defaults to storeOn: which I think is wrong, but I would hardly stand a chance changing that :P So my global goal here is to avoid any kind of asString sends while pushing stuff on a stream. Sadly this happens more often than I thought :/ ============ Sven: Maybe this discussion should happen on the mailing list ? Changing String>>#printOn: might be hard, but #<< is much more recent, no ? Could it not be changed to do what you want ? Like Streamm>><< anObject self nextPutAll: anObject asString Another point is that #asString is not so efficient, since it creates throwaway Strings.
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? Shouldn't it be printAsString: ?
https://pharo.fogbugz.com/f/cases/11536/Add-Stream-printString
============
Camillo: This method should be added to avoid many asString sends.
Example: stream nextPutAll: #('ABC') asString could be written as stream printString: #('ABC').
This is a common extension of the following pattern: stream nextPutAll: #('ABC') printString could be written as stream print: #('ABC').
============ Sven: And what about #print: as implemented by Transcripts and SocketStreams ?
It is shorter. Feels more familiar.
============ Camillo: #print: is already implement and doesn't solve the stream nextPutAll: foo asString case. Since you cannot simply write stream print: foo, since you get quotes added for Strings.
Ok, I admit that with decent design you can avoid this, since it should almost never happen that you have a String or a non string object in the same variable, right?
============ Sven: Yeah, that String issue is a bit annoying sometimes. Indeed there is Stream>>#print: already.
But look:
ThreadSafeTranscript>>#print: anObject
self nextPutAll: anObject asString
how about that ?
There is also #<< whose implementation is even weirder, but it is handy.
The question remain: when do you want to mix Strings and other objects as arguments ?
============ Camillo: - #<< is basically a lazy combination of #nextPut: and #nextPutAll: - #print: should call #printOn: on the initial argument, which for strings defaults to storeOn: which I think is wrong, but I would hardly stand a chance changing that :P
So my global goal here is to avoid any kind of asString sends while pushing stuff on a stream. Sadly this happens more often than I thought :/
============ Sven: Maybe this discussion should happen on the mailing list ?
Changing String>>#printOn: might be hard, but #<< is much more recent, no ? Could it not be changed to do what you want ? Like
Streamm>><< anObject self nextPutAll: anObject asString
Another point is that #asString is not so efficient, since it creates throwaway Strings.
-- best, Eliot
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. Regards!
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 Cheers, Max
Regards!
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.
Cheers, Max
Regards!
-- best, Eliot
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 ? Do we really need this ? Sven
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? Cheers, Max
Sven
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
participants (4)
-
Eliot Miranda -
Esteban A. Maringolo -
Max Leske -
Sven Van Caekenberghe