Object>>printOn: refined.
Locked
12
12
 
|
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: aStreamEnjoy --Trygve --
The essence of object orientation is
that objects collaborate to achieve a
goal. |
|
Hi Trygve! We do this already in Morph >> #printOn:. There, the format is a Morph<knownName>(identityHash) Best, Marcel
|
|
|
In reply to this post by Trygve
Hi
> On 02.06.2020, at 14:10, Trygve Reenskaug <[hidden email]> 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 I'd rather not increase any complexity in Object. Besides, both oop and identityHash are too low-level for the average work-flow. Teaching user to think in these numbers is, IMHO, not the right direction. -1. Best regards -Tobias |
|
|
There is also the possibility to change Object >> #defaultLabelForInspector, which is virtually in The "Tools" package. :-) Best, Marcel
|
|
|
In reply to this post by Tobias Pape
> Teaching user to think in these numbers is, IMHO, not the right direction. It is important to teach users about object identity somehow. Best, Marcel
|
|
|
> On 02.06.2020, at 14:49, Marcel Taeumel <[hidden email]> wrote: > > > Teaching user to think in these numbers is, IMHO, not the right direction. > > It is important to teach users about object identity somehow. Maybe, but if so, not by telling people that/how/.. objects map to numbers :) -t > > Best, > Marcel >> Am 02.06.2020 14:38:46 schrieb Tobias Pape <[hidden email]>: >> >> Hi >> >> > On 02.06.2020, at 14:10, Trygve Reenskaug 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 >> >> I'd rather not increase any complexity in Object. >> Besides, both oop and identityHash are too low-level for the average work-flow. >> Teaching user to think in these numbers is, IMHO, not the right direction. >> >> -1. >> >> Best regards >> -Tobias >> >> > |
|
|
Hmm... one could add an increasing number, to be reset on system startup. "Hello sir! This is array number 12 you have there. I wonder how much arrays you will come across today?" :-D "No, sir. Yesterday's array number 12 is long gone." Best, Marcel
|
|
|
> On 02.06.2020, at 15:09, Marcel Taeumel <[hidden email]> wrote: > > Hmm... one could add an increasing number, to be reset on system startup. "Hello sir! This is array number 12 you have there. I wonder how much arrays you will come across today?" :-D > > "No, sir. Yesterday's array number 12 is long gone." > I think Object>>printOn: is fine as is. Please don't touch it. :) Best regards -Tobias > Best, > Marcel >> Am 02.06.2020 15:05:52 schrieb Tobias Pape <[hidden email]>: >> >> >> > On 02.06.2020, at 14:49, Marcel Taeumel wrote: >> > >> > > Teaching user to think in these numbers is, IMHO, not the right direction. >> > >> > It is important to teach users about object identity somehow. >> >> Maybe, but if so, not by telling people that/how/.. objects map to numbers :) >> -t >> >> > >> > Best, >> > Marcel >> >> Am 02.06.2020 14:38:46 schrieb Tobias Pape : >> >> >> >> Hi >> >> >> >> > On 02.06.2020, at 14:10, Trygve Reenskaug 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 >> >> >> >> I'd rather not increase any complexity in Object. >> >> Besides, both oop and identityHash are too low-level for the average work-flow. >> >> Teaching user to think in these numbers is, IMHO, not the right direction. >> >> >> >> -1. >> >> >> >> Best regards >> >> -Tobias >> >> >> >> >> > >> >> >> > |
|
|
>I think Object>>printOn: is fine as is. Please don't touch it. :) I am talking about #defaultLabelForInspector. Trygve raised a very important concern. Best, Marcel
|
|
|
> On 02.06.2020, at 16:35, Marcel Taeumel <[hidden email]> wrote: > > >I think Object>>printOn: is fine as is. Please don't touch it. :) > > Sorry, for the confusion. You are right. Especially since "super printOn: stream" is frequently used. > > I am talking about #defaultLabelForInspector. Trygve raised a very important concern. That's right! -t > > Best, > Marcel >> Am 02.06.2020 16:30:54 schrieb Tobias Pape <[hidden email]>: >> >> >> > On 02.06.2020, at 15:09, Marcel Taeumel wrote: >> > >> > Hmm... one could add an increasing number, to be reset on system startup. "Hello sir! This is array number 12 you have there. I wonder how much arrays you will come across today?" :-D >> > >> > "No, sir. Yesterday's array number 12 is long gone." >> > >> I think Object>>printOn: is fine as is. Please don't touch it. :) >> >> Best regards >> -Tobias >> >> > Best, >> > Marcel >> >> Am 02.06.2020 15:05:52 schrieb Tobias Pape : >> >> >> >> >> >> > On 02.06.2020, at 14:49, Marcel Taeumel wrote: >> >> > >> >> > > Teaching user to think in these numbers is, IMHO, not the right direction. >> >> > >> >> > It is important to teach users about object identity somehow. >> >> >> >> Maybe, but if so, not by telling people that/how/.. objects map to numbers :) >> >> -t >> >> >> >> > >> >> > Best, >> >> > Marcel >> >> >> Am 02.06.2020 14:38:46 schrieb Tobias Pape : >> >> >> >> >> >> Hi >> >> >> >> >> >> > On 02.06.2020, at 14:10, Trygve Reenskaug 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 >> >> >> >> >> >> I'd rather not increase any complexity in Object. >> >> >> Besides, both oop and identityHash are too low-level for the average work-flow. >> >> >> Teaching user to think in these numbers is, IMHO, not the right direction. >> >> >> >> >> >> -1. >> >> >> >> >> >> Best regards >> >> >> -Tobias >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> > >> >> >> > |
|
|
In reply to this post by marcel.taeumel
On Tue, Jun 2, 2020 at 4:36 PM Marcel Taeumel <[hidden email]> wrote:
Why do we even differentiate the window labels in Inspectors and Explorers ? Best, Karl
|
|
|
Hi Karl. > Why do we even differentiate the window labels in Inspectors and Explorers ? That's a different topic. ;-) Best, Marcel
|
|
|
In reply to this post by Trygve
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 <[hidden email]> 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
|
|
|
In reply to this post by Trygve
My sincere thanks for many thoughtful comments
on my small
contribution. I learned a lot from them. It is clear that my printOn:-method
should not be included in a release image due to the repercussions
on existing
documentation and training courses also because it will only be
useful to some
but confusing to others. 
Copy the method into your image if you want to try it, reset to the original version if you don't like it. --Trygve On 2020.06.02 14:10, Trygve Reenskaug wrote: I find it frustrating to open 3 inspectors on different objects, all of them titled 'aString' (or whatever), --
The
essence of object orientation is that objects collaborate
to achieve a goal. |
|
|
On 03/06/20 5:48 pm, Trygve Reenskaug wrote:
> > I clearly need to identify the objects when I see > them. I understand that other people have other models and need other > debugging aids. I believe some people don't need my /printOn:/ variant > because they simplify things by merging the concepts of class and > instance: "This class sends /open /to that class." It works well as long > as you can get away with it. +1. The fun in live programming is all about dealing directly with instances. Since instances only have numeric oops, I see no harm in using it as an identity tag. > The /printOn/:-method does not add to the complexity of the 491 methods > of class Object; it merely modifies one of them. The method is harmless > in that it does not influence program execution. +1. The only tweak I would suggest is to use class name as a prefix in lowercase to be consistent (e.g. t1, t2 for temps in disassembled code or references to dropped morphs in workspaces). nextPut: self class name withFirstCharacterDownshifted; nextPutAll: self asOop printString truncateTo: 4. rectangle12 is easier on the eye than "[12] aRectangle". A suffix of '..' to indicate truncation, perhaps. Class will have to override this method to print the name instead of classclass1233. Regards .. Subbu |
|
|
In reply to this post by marcel.taeumel
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 <[hidden email]> 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:
--
The essence of object orientation is
that objects collaborate to achieve a
goal. |
|
|
In reply to this post by Chris Muller-3
Great! So I'm not the only one believing that object orientation is
about objects. In Smalltalk, an object is an instance of a class. In
IoT, an object stands for a Thing. The same conceptual model applies
to both. Remember Alan Kay's definition of object orientation:
Thus its semantics are a bit like having thousands and thousands of computers all hooked together by a very fast network. Questions of concrete representation can thus be postponed almost indefinitely because we are mainly concerned that the computers behave appropriately, and are interested in particular strategies only if the results are off or come back too slowly. On 2020.06.03 05:15, Chris Muller
wrote:
--
The essence of object orientation is
that objects collaborate to achieve a
goal. |
|
|
In reply to this post by Chris Muller-4
> You +1'd the idea of sending #asOop from #printOn:. Nope. I +1'd the idea to be applied to #defaultLabelForInspector because of that "super" issue. Best, Marcel
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |