printOn: vs printString

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

printOn: vs printString

Alan Rodas
Hello folks

I was wondering why does Smalltlak prefer the printOn: aStream method over the printString method.

As I work with Java and C# all the time, I'm used to define a printString like method where you return a string representing the object,
and, today, having to do the same in smalltlak I unconsciously redefined the printString method. As soon as I realize that my collections were using printOn: instead of my redefined printSrting method for printing their contents, I wondered:

Why was this decision taken? I mean, every other language seems more simple (from the end user point of view, as it does not require the user to understand streams at all), In the other hand, printOn: seems more versatile.

Pointless question, I know, but I'm quite curious and I cannot seem to find anything about this, and I though that you guys may know.

Cheers
--
Alan Rodas Bonjour

Reply | Threaded
Open this post in threaded view
|

Re: printOn: vs printString

Stéphane Ducasse
printString is a template method
printOn: a hook
so you should specialize printOn:

On Jun 25, 2011, at 6:07 AM, Alan Rodas wrote:

> Hello folks
>
> I was wondering why does Smalltlak prefer the printOn: aStream method over the printString method.
>
> As I work with Java and C# all the time, I'm used to define a printString like method where you return a string representing the object,
> and, today, having to do the same in smalltlak I unconsciously redefined the printString method. As soon as I realize that my collections were using printOn: instead of my redefined printSrting method for printing their contents, I wondered:
>
> Why was this decision taken? I mean, every other language seems more simple (from the end user point of view, as it does not require the user to understand streams at all), In the other hand, printOn: seems more versatile.
>
> Pointless question, I know, but I'm quite curious and I cannot seem to find anything about this, and I though that you guys may know.
>
> Cheers
> --
> Alan Rodas Bonjour
>


Reply | Threaded
Open this post in threaded view
|

Re: printOn: vs printString

NorbertHartl
In reply to this post by Alan Rodas

Am 25.06.2011 um 06:07 schrieb Alan Rodas:

> Hello folks
>
> I was wondering why does Smalltlak prefer the printOn: aStream method over the printString method.
>
> As I work with Java and C# all the time, I'm used to define a printString like method where you return a string representing the object,
> and, today, having to do the same in smalltlak I unconsciously redefined the printString method. As soon as I realize that my collections were using printOn: instead of my redefined printSrting method for printing their contents, I wondered:
>
> Why was this decision taken? I mean, every other language seems more simple (from the end user point of view, as it does not require the user to understand streams at all), In the other hand, printOn: seems more versatile.
>
> Pointless question, I know, but I'm quite curious and I cannot seem to find anything about this, and I though that you guys may know.

How do end user interfere with the programming language?  If your user is a developer than the statement "..does not require the use to understand streams at all..." is somewhat strange because it is something very fundamental a good developer should know.

Anyway, there is printString that produces a String and it uses printOn: to print on a stream that is used to build the string. For the sole usage you just need to know printString. If you start to print over a hierarchy of objects you see it very well why you should use streams.
This is easy to explain from a java perspective. In Java a String is immutable and we know that concatenating produces a string for every combination of other strings. That is the reason why you need to use StringBuffer/StringBuilder if you don't want to lose performance and memory. And that is something other programming languages force you to know.
A stream is something you can write subsequently on no matter how many objects write on it. You just hand the stream from on object to another and only the last one needs to do the string conversion. As Object provides this functionality you should implement printOn: on your objects.

Norbert


Reply | Threaded
Open this post in threaded view
|

Re: printOn: vs printString

Alan Rodas
How do end user interfere with the programming language?  If your user is a developer than the statement "..does not require the use to understand streams at all..." is somewhat strange because it is something very fundamental a good developer should know.

As I teach introductory OOP, the kids always want to print their object, and they don't yet know anything about streams. But I realize that it's fundamental for any programmer to know.
 
Anyway, there is printString that produces a String and it uses printOn: to print on a stream that is used to build the string. For the sole usage you just need to know printString. If you start to print over a hierarchy of objects you see it very well why you should use streams.
This is easy to explain from a java perspective. In Java a String is immutable and we know that concatenating produces a string for every combination of other strings. That is the reason why you need to use StringBuffer/StringBuilder if you don't want to lose performance and memory. And that is something other programming languages force you to know.
A stream is something you can write subsequently on no matter how many objects write on it. You just hand the stream from on object to another and only the last one needs to do the string conversion. As Object provides this functionality you should implement printOn: on your objects.

Norbert

Completely makes sense now.

Thanks guys.



--
Alan Rodas Bonjour