+1 for #basicPrintOn: (sub classes might want to re-use base implementation) -1 for #basicDisplayOn: (not necessary and by definition no base implementation could satisfy all clients)
On 08 Jan 2014, at 1:05 AM, Esteban A. Maringolo <emaring...@gmail.com> wrote: I don't want to add more fire to this... but I would even add a #basicPrintOn: and a #basicDisplayOn: in Object. The default #printOn: and #displayOn: would be based on these basic implementations. :) Esteban A. Maringolo 2014/1/6 Tudor Girba <tu...@tudorgirba.com>: > +1 > > > On Mon, Jan 6, 2014 at 4:19 PM, Stéphane Ducasse <stephane.duca...@inria.fr> > wrote: >> >> + 1 >> >>>>>> 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. >>>>> >>>>> Not necessarily domain objects only. >>>>> >>>>> Some core objects (Blocks, CompiledMethods, etc.) could benefit from >>>>> having a developer string representation (#printString) and a UI >>>>> string representation (#displayString). >>>> >>>> I don't really understand why. How would you distinguish between which >>>> (kinds of) core objects and which not? Will you not end up with a >>>> displayString on Object again? >>> >>> Yes, I want displayString on Object. >>> >>> What I don't like is #asString in Object. >>> >>> I want to be able to do: >>> Transcript show: anyObject displayString. >>> >>> Without getting a single quoted output if anyObject was a String. >>> >>> Regards. >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"
