Hi Otto, 2014/1/3 Otto Behrens <[email protected]>: >> #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.
In my opinion it is not mandatory to call super. Every object is responsible for the implementation. Ej... numbers, dates, and other "scalar like" objects. > 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. The #storeOn: approach is obsolete, IMHO. It assumes a predefined serialization scheme, which is basically an smalltalk expression to build the object, but as soon as the object graph gets complex, it becomes unusable. It is useful only for magnitudes and other "standalone" objects. >> #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? I never fully understood the "intention" of #asString other than to convert the object to the String "protocol". But I don't use its answer for anything UI-dependant. That's why I have my own #displayOn: and #displayString methods. >> #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... > Which means that by default, both printString and storeString can call > asString, and asString is the 'lowest level'? Any "store" (serialization) should have it's own selector. And most of the times it is implemented using a visitor pattern with double dispatch instead of a simple text append to a Stream. Nowadays it is more common/useful to serialize to JSON than to a smalltalk expression. Regards,
