[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