+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 <[email protected]> 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 <[email protected]> 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"

Reply via email to