+1. In all tools I wrote, I felt the need for some sort of #displayString, and sooner or later I introduced it in some form. Doru On Fri, Jan 3, 2014 at 1:39 PM, Carlo <snoobabk@gmail.com> wrote:
To me #asString is meant to be used when you need an object with the String protocol. As mentioned it looks like the seaside #asString and #greaseString are meant for displaying which causes the confusion but Iâm not sure why #displayString was removed apart from the obvious reasons of trying to cater for common denominator across Smalltalk dialects.
In my codebases I also tend to use #asString for displaying but have tried to move to a #displayString and #displayOn: protocol for these purposes.
Regards Carlo
On 03 Jan 2014, at 1:24 PM, Otto Behrens <otto@finworks.biz> wrote:
#printString and #printOn: protocol should be used for printing and #asString for conversion. This implies that #asString should not depend on #print protocol.
Ah, I used it the other way around: printOn depends on asString. I saw 'conversion' as the lower level.
Why do you distinguish here between conversion and 'printing'? Especially if displayString is being replaced with asString - to me that sounds against your thinking in principle.
If we are going to use #asString to mimic #displayString (instead of as a conversion method) then to me #asString should be viewed at a higher level abstraction than #printOn:. If not then we can run into these issues when calling the higher-level abstraction from a lower level in the same objectt, as you mentioned. Calling #printString from #asString from an API perspective should not cause issues (as displaying something is very different from converting something) so Iâd say this is an API design problem.
Yes, I think the API could be clearer. So this becomes the essence of the question here: What is the meaning of these methods from an API perspective?
Thanks for the response
-- www.tudorgirba.com "Every thing has its own flow"