On 4 January 2014 13:22, Bert Freudenberg <bert at freudenbergs.de> wrote:
>
> On 03.01.2014, at 21:31, Frank Shearar <frank.shearar at gmail.com> wrote:
>
>> 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
>
> You mean, deprecate Object>>#asString?
>
> Sounds right, although it is quite handy at times ;)

Yes, deprecate Object >> #asString, and also verify that the various
implementors of #printString, #printOn:, #asString and so on work the
way they should, and make sense according to the purpose Martin
listed.

frank

> - Bert -
>
>
>>> 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
>>>>
>>>
>>>
>>>
>>>
>>
>
>