On 20 July 2016 at 19:47, tim Rowledge <tim at rowledge.org> wrote:

>
> > On 19-07-2016, at 1:35 PM, Peter Crowther <peter at ozzard.org> wrote:
> >
> > On 19 July 2016 at 18:43, tim Rowledge <tim at rowledge.org> wrote:
> > [...]
> > the displaying morph has no idea about any rounding, limits, scaling etc
> of the value it might have to display…
> >
> > Therein lies the problem, I fear.  There's a reason for models and views…
>
> The problem is that a general purpose ‘display a string’ morph can’t know
> enough to display a string representing a number to any special format, and
> so has to rely upon the number value being ‘reasonable’. Which is of course
> a bit of a problem since numbers are well known for being unreliable jerks
> with bad manners.
>

Quite.  The interesting architectural question is then where to put the
cat-herder ("development manager") that converts between really useful data
from unreliable jerks with bad manners (call these "developers" or
"managers" as you prefer) and easy-to-consume data in an expected format
for those on the other side (call these ditto).

I'm presently dealing with a large legacy* desktop stats application that's
traditionally done all its rounding in the stats functions and handed
ready-formatted strings to the output template system for printing.  We're
migrating to an approach where the stats functions are exposed to new
consumers that expect numeric data, so the rounding and formatting needs to
be described by the output template and the template processing system
needs to be extended to cope.  I feel your pain!

Cheers,

- Peter

P.S. Strange opcode back atcha: BEA - Bitwise Exclusive-And.

* Started in Fortran 20+ years ago, went to mixed Fortran, x86 assembler
and Visual Basic, now all in C# - interesting how times change!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160721/899c5711/attachment.htm