Curry Kenworthy wrote:
> Richard:
> > 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.
>
> I don't believe for a moment that numberFormat style would lose in a
> straight competition to format style for people with zero related
> experience to either.
I must admit I have neither the methodological background nor the
resources to conduct such a study myself, hence my reliance here on mere
heuristics.
The link I included in my other post about cognitive load may be
interesting, though in a more general sense. Of course that researcher
wasn't comparing two different ways to format numbers in LC, but there
may be aspects of his research which could guide a more detailed
assessment here if needed.
That's a big "if", though, because I agree that in both cases cog. load
is small enough that the distance between both forms is almost certainly
shorter than this thread. :)
I just observe that we talk about numberFormat here a few times a year,
even among people who've been using it for decades.
But I can't recall the last time we saw questions here about the format
function. More often, as with Paul's post, when format is mentioned
here it's as a solution.
> I want "8.9" and I type "0.0" - it's so easy.
Sure, but by itself it doesn't do anything observable.
With format(), you put something in and get something else out in one
statement.
With numberFormat, you first change an abstraction in the engine, then
do something to a value elsewhere, and if you remembered to do it in the
right order, and within a single handler, you'll get what you were
looking for.
That is, unless you've forgotten that you'd set the numberFormat to some
value further up in the handler for some other reason than the place you
happen to be typing in now some 50 lines later, where you're seeing
values that aren't what you had expected because you'd overlooked that
the numberFormat setting you'd done for one thing 50 lines up is still
affecting everything afterward until you reset it. (Who among us has
never had that happen to them?) :)
> Nor do I think numberFormat is mostly useful for legacy code and old
> timers, or that more intuitive implies an inferior method. Anything
> but!
Wholeheartedly agree, which is why I wrote:
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.
> With both, we can both be happy I'm sure! Always enjoy talking with
> you.
Amen to that, Brother Kenworthy.
--
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
