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