<div dir="ltr">On 20 July 2016 at 19:47, tim Rowledge <span dir="ltr"><<a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 19-07-2016, at 1:35 PM, Peter Crowther <<a href="mailto:peter@ozzard.org">peter@ozzard.org</a>> wrote:<br>
><br>
> On 19 July 2016 at 18:43, tim Rowledge <<a href="mailto:tim@rowledge.org">tim@rowledge.org</a>> wrote:<br>
> [...]<br>
> the displaying morph has no idea about any rounding, limits, scaling etc of the value it might have to display…<br>
><br>
</span>> Therein lies the problem, I fear. There's a reason for models and views…<br>
<br>
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.<br></blockquote><div><br></div><div>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).<br><br></div><div>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!<br><br></div><div>Cheers,<br></div><div><br></div><div>- Peter<br><br></div><div>P.S. Strange opcode back atcha: BEA - Bitwise Exclusive-And.<br><br></div><div>* Started in Fortran 20+ years ago, went to mixed Fortran, x86 assembler and Visual Basic, now all in C# - interesting how times change!<br></div></div></div></div>