[Glass] [Pharo-dev] printString and asString

[Otto Behrens]

Thank you everyone for your comments.

I agree with Martin's comments and Stef's most recent one. Some of the
messages may not have reached the other lists as this was actually
posted to glass and pharo.

Is this the right conclusion of what we're going to do now?

- On Pharo and GemStone, we will remove the asString behaviour from
Object. Perhaps this is just an item on the list to deprecate and
gradually remove. Practically, a lot of people would not be using
asString in the best way, right?
- Subclasses that implement asString inappropriately (i.e. non
CharacterCollection like things)
- printString and asString will then become independent, mostly
(especially on Object)
- printString would generally be used to display a 'debugging' view of
an object, to be used for example in the inspector.

This brings back a question regarding displayString, or something
similar. It seems as if many people need something like this.

I need for example a string representation of objects generally to
display in anchors in our seaside application. We have a class
DomainObject from which most of our classes inherit, so this is
probably the place to add a 'displayString' for something like this.

Thanks
Otto


On Sat, Jan 4, 2014 at 1:47 PM, Stéphane Ducasse
<stephane.ducasse at inria.fr> wrote:
>
> And number, no? For me as* methods are for conversion between types. E.i. if
> you have string and want it as Integer you use asInteger.
>
>
> no the point is exactly that :)
> conversion between polymorphic objects
>
> asFloat
> asInteger
> asFraction
>
>
>
> asString
> asSymbol
> asByteArray
>
> asArray
> asSet
>
> not defined in Object :)
>
>
>
> Uko
>
>
> #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
>
>