[squeak-dev] Object>>printOn: refined.

David T. Lewis lewis at mail.msen.com
Thu Jun 4 14:11:54 UTC 2020


I have added it to my image and I find it to be helpful. It gives a nice
indication of object identity, and it does not get in the way of anything
that I do.

Thanks,
Dave

On Thu, Jun 04, 2020 at 07:32:52AM +0200, Trygve Reenskaug wrote:
> Quite.?? My small /printOn:/ goodie is designed to permeate the whole 
> image. It will not be part of a release image; people who like it add it 
> to their image; others don't have to see it.
> 
> On 2020.06.03 21:56, Chris Muller wrote:
> >Hi Marcel,
> >
> >It seems there are a couple??of different dimensions to consider.?? You 
> >+1'd the idea of sending #asOop from #printOn:.?? I'm definitely a -1 
> >on that, because it would force everywhere that doesn't want id to 
> >override printOn:, and they wouldn't even be able to call "super"!?? 
> >And even if they DO want id printing, overriding #asOop means they're 
> >forced to??mix concatenation with streaming, which isn't a good idea.?? 
> >To stay with streaming, you would at least want a,#printOopOn:, but 
> >that name is too domain-specific.?? (#asOop is already a common 
> >selector in persistence frameworks, I think).
> >
> >A generic, supplementary printing method that works on a Stream avoids 
> >those issues, and can be either a no-op in Object, OR, 
> >Object>>#printOn: could check if it #respondsTo: it, allowing the 
> >supplementary??method to be provided on Object by external frameworks 
> >without dirtying the Kernel package.
> >
> >Over the years, I've found having a separate, String-based "id" 
> >representation (that is not always it's oop / oid), and not any of its 
> >other attributes of its standard #printString, to be a useful 
> >extrusion of behavior for disparate domain hierarchies to inherit 
> >rather than each implement their own.
> >
> >Best,
> >?? Chris
> >
> >
> >
> >
> >On Wed, Jun 3, 2020 at 3:24 AM Marcel Taeumel <marcel.taeumel at hpi.de 
> ><mailto:marcel.taeumel at hpi.de>> wrote:
> >
> >    Hi Chris.
> >
> >    > Seeing just their identifications removes a level of formality
> >    that seems to foster a better UI "connection" to the objects.
> >
> >    Domain-specific objects can provide a good-enough identification
> >    in their #printOn: specialization. Maybe the class name is part of
> >    it. Maybe not. If you develop a database, for example, you surely
> >    have another notion of identity. Meaning, other than Object >>
> >    #identityhash or #oop. That other notion of (compact) identity
> >    should then be part of an object's print-string that is part of
> >    the database.
> >
> >    Yet, nothing one can foresee, when thinking about Object >>
> >    #printOn:. There, you have only the meta-object protocol at hand:
> >    class name, identity hash, maybe ref counter? :-D Having a new
> >    subclass of Object, what should that #printOn: look like
> >    out-of-the-box? The class name is fine. So you can actually see
> >    that your new class' instances are populating the world. Next step
> >    should be to implement a custom #printOn: in that new class.
> >
> >    Best,
> >    Marcel
> >>
> >>    Am 03.06.2020 05:16:31 schrieb Chris Muller <asqueaker at gmail.com
> >>    <mailto:asqueaker at gmail.com>>:
> >>
> >>    Hi Trygve,
> >>
> >>    Of all the attributes that objects print, I find the "type"
> >>    (class) to be one of the least interesting.?? It's usually already
> >>    obvious in its contextual usage. Indeed, it is the "identity"
> >>    that I, too, am??interested in seeing printed.?? My solution since
> >>    2006 has been an override of??#printOn: that adds a one-line
> >>    dispatch to #printIdentificationOn:.?? I then take care in my
> >>    #printIdentificationOn: implementations to keep the printing as
> >>    terse as it can be, and sans any line endings,??to serve this
> >>    seemingly recurring use-case I have of wanting a "short version"
> >>    of an object's string.?? For example,??when printing the elements
> >>    of a collection.?? Having entire domain hierarchies exclude the
> >>    type entirely from their printString's has been a fantastic
> >>    experience. Seeing just their identifications removes a level of
> >>    formality that seems to foster a better UI "connection" to the
> >>    objects.
> >>
> >>    Regards,
> >>    ?? Chris
> >>
> >>    On Tue, Jun 2, 2020 at 7:10 AM Trygve Reenskaug
> >>    <trygver at ifi.uio.no <mailto:trygver at ifi.uio.no>> wrote:
> >>
> >>        I find it frustrating to open 3 inspectors on different
> >>        objects, all of them titled 'aString' (or whatever),
> >>        IMO, it is much better to open them on the 3 objects: [1234]
> >>        aString, [3456] a String, [4567 a String.
> >>        The numbers in square brackets stand for the objects /oop/,
> >>        actually its /identityHash/. They can be a 7-digit numbers;
> >>        much too long for my short-time memory to hold many of them.
> >>        I therefore truncate the number to 4 digits, accepting that I
> >>        may, in rare cases, get 2 objects with the same identifier.
> >>
> >>        I'm running 'Squeak5.3'.
> >>
> >>            *Object>>printOn: aStream*
> >>            ?????????????? "Append to the argument, aStream, a sequence of
> >>            characters that identifies the receiver."
> >>            ?????????????? " The previous version identified the class, 
> >>            not
> >>            the instance "
> >>            ?????????????? " This new version identifies the instance with
> >>            its oop. "
> >>            ?????????????? " I arbitrarily truncate the oop to 4 digits to
> >>            simplify reading. "
> >>
> >>            ?????????????? | title |
> >>            ?????????????? title := self class name.
> >>            ?????????????? aStream
> >>            ?????????????????????? nextPutAll: '[' , (self asOop 
> >>            printString
> >>            truncateTo: 4) , ']' ;
> >>            ?????????????????????? nextPutAll: (title first isVowel 
> >>            ifTrue: ['an
> >>            '] ifFalse: ['a ']);
> >>            ?????????????????????? nextPutAll: title
> >>
> >>        Enjoy
> >>        --Trygve
> >>        -- 
> >>
> >>        /The essence of object orientation is that objects
> >>        collaborateto achieve a goal. /
> >>        Trygve Reenskaug mailto: trygver at ifi.uio.no
> >>        <mailto:%20trygver at ifi.uio.no>
> >>        Morgedalsvn. 5A http://folk.uio.no/trygver/
> >>        N-0378 Oslo http://fullOO.info
> >>        Norway??????????????????????????????????????????Tel: (+47) 468 58 
> >>        625
> >>
> >>
> >
> 
> -- 
> 
> /The essence of object orientation is that objects collaborateto achieve 
> a goal. /
> Trygve Reenskaug mailto: trygver at ifi.uio.no <mailto:%20trygver at ifi.uio.no>
> Morgedalsvn. 5A http://folk.uio.no/trygver/
> N-0378 Oslo http://fullOO.info
> Norway??????????????????????????????????????????Tel: (+47) 468 58 625
> 

> 



More information about the Squeak-dev mailing list