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
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
