Hi Dave, Hi Chris, Hi all,
I noticed that there are a couple of do-it tools in Squeak that use #asString instead of #printString for displaying the result of an evaluation. This includes print-it in the search bar (SearchBar>>#printIt:result:), DoItFirst, the emergency evaluator, the CommandShell, and possibly others. This leads to strange outputs in some cases such as ByteArrays (see screenshot). I argue that generally, in do-it and inspection contexts, #printString should be preferred over #asString as the former provides more context (such as distinguishing between '2' and 2) and the latter has the semantics of a conversion only.
If you agree with me, I will be happy to patch the senders I found in the Trunk and invite you to fix yours in external packages.
Best, Christoph
--- Sent from Squeak Inbox Talk
Hi Christoph,
Thanks for the heads up on usage in CommandShell, I will take a look at it.
Overall, I think that the method comments provide good guidance, so #asString is for conversion and #printString is for printing. So I think you are right to say that #printString is appropriate for displaying a description of the results of a calculation.
Dave
On 2023-11-12 14:08, christoph.thiede@student.hpi.uni-potsdam.de wrote:
Hi Dave, Hi Chris, Hi all,
I noticed that there are a couple of do-it tools in Squeak that use #asString instead of #printString for displaying the result of an evaluation. This includes print-it in the search bar (SearchBar>>#printIt:result:), DoItFirst, the emergency evaluator, the CommandShell, and possibly others. This leads to strange outputs in some cases such as ByteArrays (see screenshot). I argue that generally, in do-it and inspection contexts, #printString should be preferred over #asString as the former provides more context (such as distinguishing between '2' and 2) and the latter has the semantics of a conversion only.
If you agree with me, I will be happy to patch the senders I found in the Trunk and invite you to fix yours in external packages.
Best, Christoph
Sent from Squeak Inbox Talk
But a TestCase prolly deserves use of #asString, I’d think. Yeah?
••• rabbit ❤️🔥🐰
On Sun, Nov 12, 2023 at 13:23, <[lewis@mail.msen.com](mailto:On Sun, Nov 12, 2023 at 13:23, <<a href=)> wrote:
Hi Christoph,
Thanks for the heads up on usage in CommandShell, I will take a look at it.
Overall, I think that the method comments provide good guidance, so #asString is for conversion and #printString is for printing. So I think you are right to say that #printString is appropriate for displaying a description of the results of a calculation.
Dave
On 2023-11-12 14:08, christoph.thiede@student.hpi.uni-potsdam.de wrote:
Hi Dave, Hi Chris, Hi all,
I noticed that there are a couple of do-it tools in Squeak that use #asString instead of #printString for displaying the result of an evaluation. This includes print-it in the search bar (SearchBar>>#printIt:result:), DoItFirst, the emergency evaluator, the CommandShell, and possibly others. This leads to strange outputs in some cases such as ByteArrays (see screenshot). I argue that generally, in do-it and inspection contexts, #printString should be preferred over #asString as the former provides more context (such as distinguishing between '2' and 2) and the latter has the semantics of a conversion only.
If you agree with me, I will be happy to patch the senders I found in the Trunk and invite you to fix yours in external packages.
Best, Christoph
Sent from Squeak Inbox Talk
Hi Christoph,
I noticed that there are a couple of do-it tools in Squeak that use #asString instead of #printString for displaying the result of an evaluation. This includes print-it in the search bar (SearchBar>>#printIt:result:), DoItFirst, the emergency evaluator, the CommandShell, and possibly others. This leads to strange outputs in some cases such as ByteArrays (see screenshot). I argue that generally, in do-it and inspection contexts, #printString should be preferred over #asString as the former provides more context (such as distinguishing between '2' and 2) and the latter has the semantics of a conversion only.
I generally agree with that, because do-it and inspection contexts are *inward* looking tools of the Smalltalk domain, and therefore should use the utilitarian method, #printString. I can't think of any reason why an Inspector would use #asString instead of #printString, but are you also concerned about #asExplorerString?
If you agree with me, I will be happy to patch the senders I found in the Trunk and invite you to fix yours in external packages.
External packages, OTOH, usually want to represent objects in an outward-looking fashion, toward users. They may have chosen #asString for that reason, or to utilize an override-hook for rendering in an "app" context.
I must admit I've been guilty lately of treating #printString as my #asString -- overriding the default to omit the "a [Classname]" -- since it's often the least interesting thing to know about an object when they're in context.
Best, Chris
Hi Chris, Hi Dave,
thanks for the feedback!
I can't think of any reason why an Inspector would use #asString instead of #printString, but are you also concerned about #asExplorerString?
#asExplorerString is an unfortunate name but luckily resolves to a printString ... at least in the base case. :-)
External packages, OTOH, usually want to represent objects in an outward-looking fashion, toward users. They may have chosen #asString for that reason, or to utilize an override-hook for rendering in an "app" context.
Depends on the context, I would say. :-) Yes for end-user applications, but CommandShell or TelegramBot are developer and inspection tools themselves.
Best, Christoph
________________________________ Von: Chris Muller ma.chris.m@gmail.com Gesendet: Montag, 13. November 2023 06:26:41 An: Thiede, Christoph Cc: squeak-dev@lists.squeakfoundation.org Betreff: Re: #asString vs #printString for do-its
Hi Christoph,
I noticed that there are a couple of do-it tools in Squeak that use #asString instead of #printString for displaying the result of an evaluation. This includes print-it in the search bar (SearchBar>>#printIt:result:), DoItFirst, the emergency evaluator, the CommandShell, and possibly others. This leads to strange outputs in some cases such as ByteArrays (see screenshot). I argue that generally, in do-it and inspection contexts, #printString should be preferred over #asString as the former provides more context (such as distinguishing between '2' and 2) and the latter has the semantics of a conversion only.
I generally agree with that, because do-it and inspection contexts are *inward* looking tools of the Smalltalk domain, and therefore should use the utilitarian method, #printString. I can't think of any reason why an Inspector would use #asString instead of #printString, but are you also concerned about #asExplorerString?
If you agree with me, I will be happy to patch the senders I found in the Trunk and invite you to fix yours in external packages.
External packages, OTOH, usually want to represent objects in an outward-looking fashion, toward users. They may have chosen #asString for that reason, or to utilize an override-hook for rendering in an "app" context.
I must admit I've been guilty lately of treating #printString as my #asString -- overriding the default to omit the "a [Classname]" -- since it's often the least interesting thing to know about an object when they're in context.
Best, Chris
I have fixed all senders of #asString in the Trunk that I could associate with the result of an evaluated expression via Morphic-ct.2139 and System-ct.1433.
Best,
Christoph
________________________________ Von: Thiede, Christoph Gesendet: Montag, 13. November 2023 19:12:27 An: Chris Muller Cc: squeak-dev@lists.squeakfoundation.org Betreff: AW: #asString vs #printString for do-its
Hi Chris, Hi Dave,
thanks for the feedback!
I can't think of any reason why an Inspector would use #asString instead of #printString, but are you also concerned about #asExplorerString?
#asExplorerString is an unfortunate name but luckily resolves to a printString ... at least in the base case. :-)
External packages, OTOH, usually want to represent objects in an outward-looking fashion, toward users. They may have chosen #asString for that reason, or to utilize an override-hook for rendering in an "app" context.
Depends on the context, I would say. :-) Yes for end-user applications, but CommandShell or TelegramBot are developer and inspection tools themselves.
Best, Christoph
________________________________ Von: Chris Muller ma.chris.m@gmail.com Gesendet: Montag, 13. November 2023 06:26:41 An: Thiede, Christoph Cc: squeak-dev@lists.squeakfoundation.org Betreff: Re: #asString vs #printString for do-its
Hi Christoph,
I noticed that there are a couple of do-it tools in Squeak that use #asString instead of #printString for displaying the result of an evaluation. This includes print-it in the search bar (SearchBar>>#printIt:result:), DoItFirst, the emergency evaluator, the CommandShell, and possibly others. This leads to strange outputs in some cases such as ByteArrays (see screenshot). I argue that generally, in do-it and inspection contexts, #printString should be preferred over #asString as the former provides more context (such as distinguishing between '2' and 2) and the latter has the semantics of a conversion only.
I generally agree with that, because do-it and inspection contexts are *inward* looking tools of the Smalltalk domain, and therefore should use the utilitarian method, #printString. I can't think of any reason why an Inspector would use #asString instead of #printString, but are you also concerned about #asExplorerString?
If you agree with me, I will be happy to patch the senders I found in the Trunk and invite you to fix yours in external packages.
External packages, OTOH, usually want to represent objects in an outward-looking fashion, toward users. They may have chosen #asString for that reason, or to utilize an override-hook for rendering in an "app" context.
I must admit I've been guilty lately of treating #printString as my #asString -- overriding the default to omit the "a [Classname]" -- since it's often the least interesting thing to know about an object when they're in context.
Best, Chris
squeak-dev@lists.squeakfoundation.org