This, yes please.
--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.
On Sat, Apr 22, 2017 at 11:21 AM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:
> 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
>
_______________________________________________
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
