#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'?