[Glass] [Pharo-dev] printString and asString

Otto Behrens otto at finworks.biz
Fri Jan 3 07:13:46 PST 2014


> #printString is used for debugging, that's why the default
> implementation shows the class name. It's implemented using #printOn:

Makes sense. So unless there's a nice symbol that one can add to show
what it is (eg #foo printString = '#foo'), implementors of printOn:
should call super printOn:, yes? In Pharo, this seems to be the
general idea.

But then printString should not be used (generally) as the mechanism
to display something to for a user, right? As this would show
something like 'a Person Otto' to the user.

Some implementors of printOn: could be renamed to storeOn:

In GemStone, the default implementation of asString is to show the class name.

> #displayString (deprecated in Pharo*) is used to display the object in
> the UI. It is implemented by means of #displayOn: (Dolphin used this
> pattern)

So we don't have this in Pharo anymore. Looks like it is mostly
asString now. But then, really,

Object asString
  ^ self printString

does not make sense?

> #asString is the toString() equivalent of other languages. In some
> cases `anObject asString asObject` should give the same object back
> (e.g. in Date, Numbers, etc.). Most of the times it is the same string
> as #printString, but it is not consistent.

The intention of #storeString implemented via #storeOn: is to do that:
(Compiler evaluate: anObject storeString) = anObject. Probably not
completely true for really complex objects...

> Ej:
> If you have aPerson:
> aPerson printString -> "aPerson ('John Doe')"
> aPerson displayString -> 'John Doe'

Ok, since displayString is gone, is it:

aPerson asString -> 'John Doe'
aPerson storeString -> "Person name: 'John Doe'"

Which means that by default, both printString and storeString can call
asString, and asString is the 'lowest level'?


More information about the Glass mailing list