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

[Curry Kenworthy via use-livecode]

Mark Waddingham:

> I can guarantee that nothing is going to happen to numberFormat
> (beyond perhaps improving its documentation) any time soon -
> if ever. Indeed, it wouldn't ever disappear just evolved (assuming
> we can figure out how to make it a) more powerful and (b) play
> more nicely with LiveCode's more modern features!).

Mark, thanks for the reassurance, that is great to hear!

I agree it would be even better if it did more. I would be thrilled if 
numberFormat can be upgraded in ways that are backward compatible.


Best wishes,

Curry Kenworthy

Custom Software Development
http://curryk.com/consulting/

___
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

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

[Mike Kerner via use-livecode]

I get that it would break existing code that relies on the behavior.  I'm
just offering to make that trade as the self-appointed spokesperson for
equal rights for all items.

On Mon, Apr 24, 2017 at 11:06 AM, Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Well as I said, the workaround is to have a function (say formatNumber)
> with 2 arguments, value and format string. Because the numberFormat is
> getting set only for that function, you can call formatNumber() and never
> have to worry about resetting numberformat again. And it's not more
> difficult to write the line of code either. In fact less so.
>
> Bob S
>
>
> > On Apr 22, 2017, at 15:42 , Richard Gaskin via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > 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?)   :)
>
>
> ___
> 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
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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

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

[Bob Sneidar via use-livecode]

Well as I said, the workaround is to have a function (say formatNumber) with 2 
arguments, value and format string. Because the numberFormat is getting set 
only for that function, you can call formatNumber() and never have to worry 
about resetting numberformat again. And it's not more difficult to write the 
line of code either. In fact less so. 

Bob S


> On Apr 22, 2017, at 15:42 , Richard Gaskin via use-livecode 
>  wrote:
> 
> 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?)   :)


___
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

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

[Mark Waddingham via use-livecode]

On 2017-04-24 16:58, Mike Kerner via use-livecode wrote:
To remind the readers, this is a database thing - null column values 
cause

issues with LC when the null value is on the tail.
All it would take is removing that one little line in the item code - 
that
line that makes items less computationally efficient than they could 
be.


That's an anomaly in revDB because revDB doesn't follow the 'trailing 
delimiter

is optional unless you want a list containing empty elements':

   http://quality.livecode.com/show_bug.cgi?id=14874

That one can be fixed either in queries (by making sure the last column 
you
select can't be NULL - or the empty string); or in code calling it by 
appending

a comma if the line ends in comma.

The engine also has a couple of anomalies with regard string-list 
processing:


   http://quality.livecode.com/show_bug.cgi?id=14875
   http://quality.livecode.com/show_bug.cgi?id=14876

Unfortunately, fixing any three of those without some sort of 
compatibility

mechanism would break large amounts of existing code which is written to
code with the issue.

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

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

[Mike Kerner via use-livecode]

To remind the readers, this is a database thing - null column values cause
issues with LC when the null value is on the tail.
All it would take is removing that one little line in the item code - that
line that makes items less computationally efficient than they could be.

On Mon, Apr 24, 2017 at 10:32 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2017-04-24 16:10, Mike Kerner via use-livecode wrote:
>
>> That's too bad.  I was hoping that I could trade deprecating
>> numberFormat for giving equal rights to the last item in a list.
>>
>
> If you mean:
>
>   the number of items in "a,b," should be 3 (and not 2)
>
> and
>
>   the number of items in "a,b,c" should be 3
>
> Then, err, no.
>
> Sorry.
>
> To paraphrase Scotty from Star Trek - "I can't change the laws of logic",
> and nor can you ;)
>
> If you want to use string lists which may contain an empty element
> then just make sure you always have a trailing delimiter.
>
> Of course, if you don't mean the above, then you might want to
> elaborate :)
>
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> ___
> 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
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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

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

[Mark Waddingham via use-livecode]

On 2017-04-24 16:10, Mike Kerner via use-livecode wrote:

That's too bad.  I was hoping that I could trade deprecating
numberFormat for giving equal rights to the last item in a list.


If you mean:

  the number of items in "a,b," should be 3 (and not 2)

and

  the number of items in "a,b,c" should be 3

Then, err, no.

Sorry.

To paraphrase Scotty from Star Trek - "I can't change the laws of 
logic",

and nor can you ;)

If you want to use string lists which may contain an empty element
then just make sure you always have a trailing delimiter.

Of course, if you don't mean the above, then you might want to
elaborate :)

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

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

[Mike Kerner via use-livecode]

That's too bad.  I was hoping that I could trade deprecating
numberFormat for giving equal rights to the last item in a list.

Say it with me now:  EQUAL RIGHTS FOR ALL ITEMS!  EVEN THE LAST ONES!

On Mon, Apr 24, 2017 at 10:06 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2017-04-22 02:51, Curry Kenworthy via use-livecode wrote:
>
>> Mark Waddingham:
>>
>>> I think this is perhaps more evidence that 'numberFormat'
>>> should probably be deprecated - or at least marked as
>>> 'present for HyperCard compatibility only and shouldn't
>>> be used in new code'.
>>>
>>
>> I emphatically disagree.
>>
>
> Don't worry - I don't entirely agree with my suggestion either :)
>
> I must confess I was being overly pejorative in order to provoke a
> conversation - something I have a tendency to do from time to time in
> order to help get a greater understanding of things.
>
> There's nothing wrong with numberFormat as a binary to text option. On
>> the contrary, it's a splendid way to present the formatting to users.
>> The array key example is an outlier case to watch out for, but it's
>> also easy to use an alternate formatting option or careful coding for
>> those rare cases.
>>
>
> I'd disagree that anything involving the use of arrays could be considered
> a 'rare case' or an 'outlier case'; so it is irksome that a feature
> (numberFormat) which is meant to make working with the display of numbers
> 'easier' is somewhat incompatible with it.
>
> I'd mind less if numberFormat was actually had wide utility - but, in
> reality,
> for all but the simplest of cases (wanting US/UK style numbers, with
> preceding or following '0's) it isn't very useful.
>
> To be fair, that is fine - the problems which keep recurring could
> probably be mostly dealt with by much better documentation of numberFormat.
> i.e. Clear explanation about how it affects computations, and when to use
> it
> and when not to
>
> That, however, does still leave me 'wanting' though. As you point out the
> *idea* is so ergonomic that it *seems* like it should be much more
> powerful,
> but it is not, and if you want to use it easily with other parts of the
> language, you are probably best not to use it at all.
>
> I can guarantee that nothing is going to happen to numberFormat (beyond
> perhaps improving its documentation) any time soon - if ever. Indeed,
> it wouldn't ever disappear just evolved (assuming we can figure out how
> to make it a) more powerful and (b) play more nicely with LiveCode's more
> modern features!).
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
>
> ___
> 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
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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

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

[Mark Waddingham via use-livecode]

On 2017-04-22 02:51, Curry Kenworthy via use-livecode wrote:

Mark Waddingham:

I think this is perhaps more evidence that 'numberFormat'
should probably be deprecated - or at least marked as
'present for HyperCard compatibility only and shouldn't
be used in new code'.


I emphatically disagree.


Don't worry - I don't entirely agree with my suggestion either :)

I must confess I was being overly pejorative in order to provoke a
conversation - something I have a tendency to do from time to time in
order to help get a greater understanding of things.


There's nothing wrong with numberFormat as a binary to text option. On
the contrary, it's a splendid way to present the formatting to users.
The array key example is an outlier case to watch out for, but it's
also easy to use an alternate formatting option or careful coding for
those rare cases.


I'd disagree that anything involving the use of arrays could be 
considered

a 'rare case' or an 'outlier case'; so it is irksome that a feature
(numberFormat) which is meant to make working with the display of 
numbers

'easier' is somewhat incompatible with it.

I'd mind less if numberFormat was actually had wide utility - but, in 
reality,

for all but the simplest of cases (wanting US/UK style numbers, with
preceding or following '0's) it isn't very useful.

To be fair, that is fine - the problems which keep recurring could
probably be mostly dealt with by much better documentation of 
numberFormat.
i.e. Clear explanation about how it affects computations, and when to 
use it

and when not to

That, however, does still leave me 'wanting' though. As you point out 
the
*idea* is so ergonomic that it *seems* like it should be much more 
powerful,

but it is not, and if you want to use it easily with other parts of the
language, you are probably best not to use it at all.

I can guarantee that nothing is going to happen to numberFormat (beyond
perhaps improving its documentation) any time soon - if ever. Indeed,
it wouldn't ever disappear just evolved (assuming we can figure out how
to make it a) more powerful and (b) play more nicely with LiveCode's 
more

modern features!).

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

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

[Curry Kenworthy via use-livecode]

Richard:

> 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.

Ha ha, and that's precisely what I love about it, in addition to the 
intuitive representation and the great syntax!


In other words, the property acts a lot like a setting. Plenty of those 
in LiveCode. That's also intuitive, efficient the way I use them, and 
something that relates well to human experience, very easy to teach and 
learn. That's a strength in my book.


I forgot to add before that numberFormat seems to have the advantage on 
data type awareness. When you don't know about it, it works anyway, 
using the default when you concatenate. When you desire a different 
result and gain awareness, you can set it, and your concatenation code 
stays the same.


With format, you must have awareness from the start. Otherwise you're 
just concatenating stuff, and then the default has to cover for you. We 
could call that a tie, but I look at two other points. The default 
superficially looks like the way numberFormat works (the syntax is just 
concatenating with no functions) and LiveCode must have that built in 
anyway, unless it throws an error. Then you must change your 
concatenation code to include the function.


Bottom line is the "0.0" representation is just too intuitive to beat. 
Cognitive load theory or not, mark my words, that representation is 
going to blow away the competition in learning. That's obvious by being 
so much closer in form to the desired result. The closer things are, 
generally the less work required to bridge them. You can give it fancy 
names, but the underlying math will hold true regardless.


Using the property like a setting is an added plus, appealing and 
intuitive for many (I'd venture to guess most) people. Some others may 
prefer format. For them, it's there to use and no one is advocating that 
it be removed or deprecated. And even if a new property were added to 
control field display, it would probably act a lot like numberFormat.


But even that wouldn't replace the need for numberFormat itself. I think 
there are so many better priorities for LiveCode's "surgeons" than 
attacking the healthy tissue. There are still LC 8/9 bugs and so on that 
need attention, and having to intervene on behalf of this feature takes 
away a lot time from submitting those bug reports and maybe doing some 
promotions and such. This is one of the good parts of LiveCode! I hope 
people don't get dazzled by trends or self-destructive. I've seen that 
happen before. Good feature, realize the value of what you have and hang 
on to it.


Best wishes,

"Uber-Mega-Doctor" Curry Kenworthy
(Richmond, my check is in the mail! Don't be stingy with the gold lettering)

Custom Software Development
LiveCode Training and Consulting
http://curryk.com/consulting/

___
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

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

[Richard Gaskin via use-livecode]

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.comhttp://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

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

[Curry Kenworthy via use-livecode]

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 predict the learning time would be a fraction; 
there's just not much to learn when the symbols look so much like the 
desired result. I'm trying to be fair and think of how hard that can be, 
but not having much luck. I want "8.9" and I type "0.0" - it's so easy. 
The hashes are just one additional step, and might not be needed the 
first time.


Nor do I think numberFormat is mostly useful for legacy code and old 
timers, or that more intuitive implies an inferior method. Anything but! 
That's why it's not unique in the world; very natural method of 
representing formatting options, and it will always be around in many 
products. You've proposed some intricate rules for evaluating the two 
formatting options, but your system and your calls lean in your 
preferred direction. That's fine. But with my rules, numberFormat 
usually dominates.


BTW, the human mind is naturally designed for some contextual awareness. 
Concatenations often happen more than one at a time, and it's set for 
those transactions, much the way we would say it in a conversation.


Talking about a subject with a person, if there's some context we need 
to keep in mind for the whole conversation, we can say that once at the 
beginning, not keep repeating it along with each point. As if I kept 
saying "with LiveCode, with LiveCode" when we all know that's the 
context of our discussions here! (Our discussions here with LiveCode, 
that is.) You already understand that fact. (I mean, the fact that it's 
LiveCode.) Of course I can replicate that memory with some extra code, 
but then the use of format has become more verbose, hasn't it? With 
numberFormat it's already done and infinitely tested, KISS and robust. 
So I just can't see that as a problem. It seems quite natural to the way 
we think, so might as well call it a plus.


Whether I'm wearing pants or just nice boxers (more often the latter 
around the house, as a wheelchair guy) must be considered in social 
transactions. I believe this mental stream of thought at the conscious 
level looks more like "set currentClothing to "boxers";answer door for a 
package;prepare to go out" than a series of function calls providing my 
clothing as a parameter. Then again, maybe that stream is different for 
different people. If so, take your pick with my blessing. I'm in boxers 
now typing this and giving my blessing; might as well have some fun, 
right? :)


The data type awareness is nothing to fret about either. I don't think 
it really requires awareness until they reach a certain point. If they 
are unaware, a conversion is going to happen anyway, by default when no 
format is set. So it's something very natural to learn about when it's 
brought to our attention by our own actions, and when we have a desire 
for a different result. And when that time comes, dang is it easy to 
learn! That was quick.


You need even more awareness to use format. And awareness is good, but 
we can't have it both ways. If format awareness is good, numberFormat 
awareness can't be bad. And vice versa. I refuse to see the argument 
framed as an old timer/legacy thing when intuitive systems will dominate 
the future. I can really appreciate the reasons why some people like 
format, and more power to them, it's a very good system. But I demand 
just as much technical respect for the numberFormat, so I won't hesitate 
to reframe the discussion.


Trends and fads change the landscape, and hype drives sales and 
adoption, but those come and go. My criteria are objective and fairly 
constant, and the numberFormat performs very well for my philosophy. 
Intuitive, useful, readable, usually less code, simple, fast to 
implement, easy to proofread. Even if LC were mutilated by removing or 
denigrating it (I hope not) other products, especially those geared 
toward numbers, would continue to use similar representations to reap 
the natural benefits of modern and intuitive formatting.


With both, we can both be happy I'm sure! Always enjoy talking with you.

Best wishes,

Curry Kenworthy

Custom Software Development
LiveCode Training and Consulting
http://curryk.com/consulting/

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:

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

[Mike Bonner via use-livecode]

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 

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

[Richard Gaskin via use-livecode]

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 

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

[Bob Sneidar via use-livecode]

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. 

Bob S


> On Apr 21, 2017, at 18:23 , Mike Kerner via use-livecode 
>  wrote:
> 
> I tend to agree.  There is nothing about "format" that is intuitive to the
> non-initiated.


___
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

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

[Mike Kerner via use-livecode]

I tend to agree.  There is nothing about "format" that is intuitive to the
non-initiated.

On Fri, Apr 21, 2017 at 8:51 PM, Curry Kenworthy via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Mark Waddingham:
> > I think this is perhaps more evidence that 'numberFormat'
> > should probably be deprecated - or at least marked as
> > 'present for HyperCard compatibility only and shouldn't
> > be used in new code'.
>
> I emphatically disagree.
>
> There's nothing wrong with numberFormat as a binary to text option. On the
> contrary, it's a splendid way to present the formatting to users. The array
> key example is an outlier case to watch out for, but it's also easy to use
> an alternate formatting option or careful coding for those rare cases.
>
> The numberFormat is very easy to read and clean, similar to formatting
> systems used by Excel and others. (Naturally SpreadLib uses it too.) People
> understand the representation intuitively, and it's also extremely popular.
>
> It provides a consistent shortcut compared to using a function several
> times, for clean code with one statement to edit, so it is compatible with
> KISS philosophy.
>
> I prefer numberFormat for most tasks and would detest having it
> deprecated. Obviously the show must go on when someone concatenates text
> with a number, so a default behavior would have to be in place for that
> regardless (unless LC would throw an error), but we would lose the
> customizable aspect. LiveCode will be disfigured if we hack off all the
> pleasant parts.
>
> It will also be less "English-like" than before if we remove the wrong
> parts. I've been working on materials for my new fluency method for
> teaching LiveCode's syntax, based on proven language learning methods and
> enhanced with my own additional techniques geared to CS and LC.
>
> This is such a readable sentence to teach and use:
>
> set the numberformat to "0.00"
>
> Although I don't have time to be as vocal an advocate as some others here
> on LC trends and directions, there's so much to be said on the subject of
> LC's English-like language, how to optimize learning and coding around it,
> and what the result offers compared to other computing languages. (But I'll
> say most of that in my upcoming book rather than here on the list.)
>
> I sure don't intend to teach the best parts of LC as deprecated or
> denigrated, so I hope the language stays intact without self-mutilation. :)
>
> Best wishes,
>
> Curry K.
>
> ___
> 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
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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

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

[Curry Kenworthy via use-livecode]

Mark Waddingham:
> I think this is perhaps more evidence that 'numberFormat'
> should probably be deprecated - or at least marked as
> 'present for HyperCard compatibility only and shouldn't
> be used in new code'.

I emphatically disagree.

There's nothing wrong with numberFormat as a binary to text option. On 
the contrary, it's a splendid way to present the formatting to users. 
The array key example is an outlier case to watch out for, but it's also 
easy to use an alternate formatting option or careful coding for those 
rare cases.


The numberFormat is very easy to read and clean, similar to formatting 
systems used by Excel and others. (Naturally SpreadLib uses it too.) 
People understand the representation intuitively, and it's also 
extremely popular.


It provides a consistent shortcut compared to using a function several 
times, for clean code with one statement to edit, so it is compatible 
with KISS philosophy.


I prefer numberFormat for most tasks and would detest having it 
deprecated. Obviously the show must go on when someone concatenates text 
with a number, so a default behavior would have to be in place for that 
regardless (unless LC would throw an error), but we would lose the 
customizable aspect. LiveCode will be disfigured if we hack off all the 
pleasant parts.


It will also be less "English-like" than before if we remove the wrong 
parts. I've been working on materials for my new fluency method for 
teaching LiveCode's syntax, based on proven language learning methods 
and enhanced with my own additional techniques geared to CS and LC.


This is such a readable sentence to teach and use:

set the numberformat to "0.00"

Although I don't have time to be as vocal an advocate as some others 
here on LC trends and directions, there's so much to be said on the 
subject of LC's English-like language, how to optimize learning and 
coding around it, and what the result offers compared to other computing 
languages. (But I'll say most of that in my upcoming book rather than 
here on the list.)


I sure don't intend to teach the best parts of LC as deprecated or 
denigrated, so I hope the language stays intact without self-mutilation. :)


Best wishes,

Curry K.

___
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