[squeak-dev] Fwd: [Pharo-dev] [Glass] printString and asString
Das.Linux at gmx.de
Fri Jan 3 20:08:11 UTC 2014
I think Martin makes a very good point about
the various *String messages.
Should we aim for that in >4.5?
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:
>> 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().
> 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).
> 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:.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1665 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140103/36063730/signature.pgp
More information about the Squeak-dev