[squeak-dev] Fwd: [Pharo-dev] [Glass] printString and asString

Bert Freudenberg bert at freudenbergs.de
Sat Jan 4 13:22:14 UTC 2014


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 ;)

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



More information about the Squeak-dev mailing list