[squeak-dev] Object>>printOn: refined.
Trygve Reenskaug
trygver at ifi.uio.no
Thu Jun 4 05:32:52 UTC 2020
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200604/99be701e/attachment.html>
More information about the Squeak-dev
mailing list
|