introducing displayString

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

introducing displayString

stepharo
hi guys

I was reading a proposal that was sent to the list and I like it.
What do you think?

Stef



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,


Reply | Threaded
Open this post in threaded view
|

Re: introducing displayString

Philippe Marschall-2
On 03.06.14 08:03, stepharo wrote:

> hi guys
>
> I was reading a proposal that was sent to the list and I like it.
> What do you think?
>
> Stef
>
>
>
> 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:.

Sounds a lot like VW. I still remember the very complex rules we had in
Seaside 2.x for when you should send #displayString, when #printString
and when #asString. In the end we built #greaseString (#seasideString
once) and everything became much simpler.

Cheers
Philippe