[Glass] printString and asString

[Martin McClure]

On 01/03/2014 12:33 AM, Otto Behrens wrote:
> Hi,
> 
> I've run into one of my favorite problems in Smalltalk and decided to
> try the list. Please don't shoot me on this one; perhaps you've run
> into it yourself. If there are discussions that I should read, please
> send me some info.

Hi Otto,

Well, you asked for comments. This is my personal opinion, which varies
quite a bit from most implementations, since it's a bit 'old-school
Smalltalk'. But I think the scheme below does fairly neatly distinguish
the purposes of the various messages, which have gotten muddied over the
years as new developers use the language somewhat differently. But maybe
it was never the way I think I remember it being. :-)


#printString and #printOn:
These should answer a human-readable description of the receiver. The
description does not need to include the class name, though it can. All
objects should respond to these messages. Generally, #printString should
be implemented in terms of #printOn: -- if you're writing to a stream
you may not want to pay the cost of creating an extra string.
#printString is the equivalent of other languages' toString().

#asString
There should not be an Object>>asString. This message is *only* for
converting string-like things to actual strings. So it would be
implemented in String (to return self) and in Symbol, and *maybe* in
things like ByteArray (where it does not *describe* the byte array, but
answers a string whose characters have the values of the bytes).

#storeString
Produces legal Smalltalk source code that when executed will produce an
equivalent object to the receiver. Needs to be implemented only for
objects that can be specified as literals in Smalltalk syntax, but could
probably be implemented for a few other simple objects.

#displayString and so on.
UI frameworks and applications will need to have their own ways of
textually representing objects, so will add their own messages such as
#displayString. The *only* messages that any application or framework
can depend on *all* objects responding to are those that it defines
itself, and #printString and #printOn:.

Regards,

-Martin