On 3 January 2014 20:08, Tobias Pape <Das.Linux at gmx.de> wrote:
> Hi,
>
> I think Martin makes a very good point about
> the various *String messages.
>   Should we aim for that in >4.5?

Yes :)

frank

> Best
>         -Tobias
>
>
> Begin forwarded message:
>
>> From: Martin McClure <martin at hand2mouse.com>
>> Subject: Re: [Pharo-dev] [Glass] printString and asString
>> Date: 3. Januar 2014 20:55:20 MEZ
>> To: Otto Behrens <otto at finworks.biz>
>> Cc: Discusses Development of Pharo <pharo-dev at lists.pharo.org>
>> Reply-To: Pharo Development List <pharo-dev at lists.pharo.org>
>>
>> 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
>>
>
>
>
>