Don't amputate numberFormat (was: affecting array keys???)

Sat Apr 22 13:21:59 EDT 2017

Bob Sneidar wrote:

 >> On Apr 21, 2017, at 18:23 , Mike Kerner wrote:
 >>
 >> I tend to agree.  There is nothing about "format" that is intuitive
 >> to the non-initiated.
 >
 > A couple years ago I had a look at format. I gave up after I got the
 > headache. I tried again today. Same results. I cannot even begin to
 > fathom the printf() C rules! I read and read and read, try examples
 > etc. but NOTHING can get me to the point where I can make "1.1" into
 > "01.10" never mind "10.2.1.6" into "010.002.001.006".
 >
 > My workaround fixes my issue, and Jacque's works also, provided you
 > put the numberFormat into a separate function so that you do not have
 > to continually keep resetting the numberformat everytime it might
 > affect *ANY* numeric value as text.

There are good benefits to having both numberFormat and the format 
function. I don't suppose Mark was serious about deprecating the former, 
just making a point about the strength of the latter.

The numberFormat property is something all of us ol' timers are 
accustomed to, and in many cases it's a good fit for what we need.  So 
that, plus decades of legacy code, give us good reasons to keep it around.

But if we step back and review the cognitive implications of using it, 
we find a few things worth considering:

NumberFormat requires contextual awareness
------------------------------------------
First and foremost, by itself it doesn't actually do anything, in terms 
of things we can see.

When we set the numberFormat, no object nor any variable value changes. 
The property's utility only becomes evident in conjunction with 
subsequent statements.

So comparing the numberFormat property to the format function by using 
single statements isn't apples-to-apples, as numberFormat will always 
require at least two statements for it to become in any way evident.

Additionally, as a property of the LC system it's not bound to anything, 
an abstraction, and one that changes again without our intervention the 
moment the current handler exits.

And then of course there's the reason this thread exists:  because the 
numberFormat property only affects things that happen after it's set, 
the interaction between the property and those subsequent statements 
isn't always clear.

If it were we wouldn't be having this discussion. :)  And because it's 
unclear, we've seen variants of this discussion every few months, even 
among people who first learned numberFormat many years ago.

Never underestimate the compounding impact on cognitive load of 
multi-statement sequence dependency.

NumberFormat requires data type awareness
-----------------------------------------
xTalks are traditionally typeless, with the respective engines 
(HyperCard, SuperCard, OMO, Gain Momentum, Toolbook, LiveCode, etc.) 
converting between strings and numbers automatically for us, behind the 
scenes.   This typelessness allows us to think in terms of what we see 
with our human eyes, without having to also conceptualize the 
representation of numeric values as they pass through CPU gates.  We do 
things with what we see in front of us, and it all just works.

Except with the numberFormat property.

Here we have one of the few times in which using an xTalk requires 
having at least some awareness that CPUs use different data types for 
arithmetic operations than they do for strings.

In some cases, getting what we want from the numberFormat property 
requires us to add additional steps in our code in order to coerce the 
value we want to be affected.  Sometimes we add a zero to coerce a 
string to a number, other times we pad or concatenate to coerce a number 
to a string.  Consider the many examples throughout this thread.

Type coercion in an xTalk?  Egads!  Yet here we are. :)

At a minimum, the numberFormat property requires at least two statements 
to be of any value at all: first setting the property, and then doing 
something that will cause it to be applied to a value.

But because we sometimes have to explicitly coerce the value, now and 
then we need at least *three* statements to get the result we're looking 
for with numberFormat.  And when that third step is needed, it's because 
we have to momentarily think like a computer.

With GUI objects as part of the core language, xTalks usually afford us 
the opportunity to code in a way that expresses the user experience.  We 
get to think like users, with the engine handling the implementation 
details to accommodate the more mundane and arcane needs of the computer.

NumberFormat introduces a moment in which we need to be aware that we're 
expressing our user interface in a machine too stupid to count past 1. 
:)  We don't otherwise need to be aware of binary representations often, 
if at all.

Of course some of the options in the format function are also dependent 
on understanding data types.  But not all of them, and if you do need to 
use those that requiring understanding types you still gain the benefit 
of having everything in the conversion happening within a single 
statement, as opposed to the multi-statement requirements for using the 
numberFormat property.

NumberFormat has limited options
--------------------------------
With just two options ("#" for zero-padding where needed, and "0" for 
required zero-padding), the scope of the numberFormat property is limited.

By itself that's a point in its favor, since there's not much to learn 
about using it (beyond the things noted above).

But it also means that sooner or later you're likely to need to use the 
format function anyway, as soon as you want padding for text, or 
scientific notation, or any of the other options it provides.

TL;DR
-----
When numberFormat can do the job and you want to use it, use it.  For 
certain tasks it may be somewhat simpler than the format function.

But when we consider the full cognitive requirements for using 
numberFormat, esp. its dependency on multi-statement context, I think it 
would be difficult to come up with a cognitive-load metric which could 
demonstrate that it's actually easier to learn than the subset of 
options needed to get the same result with the format function.

Just because we learned it years ago doesn't mean it's necessarily 
easier to learn for anyone else starting out today.

Please remember that the reason we didn't learn the format function back 
then it because it didn't exist in any xTalk in those days. :)

Moreover, since the format function covers far more ground, once you 
learn the options needed to get simple numeric formatting results you're 
already well oriented for learning any other options you might need as 
you go later one.

PS: All of these recurring discussions around formatting data reinforce 
the value of adding a display formatting property to the field object.

There are still use-cases for both numberFormat and format, but there 
are so many precedents in other tools for defining display format in the 
object used for display that I think when that's what's needed it would 
be the simplest to learn.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com