[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
|