We've talked about this topic so much that now it almost seems a waste
to let it go without trying to make some progress. :)
Mark:
> I'd disagree that anything involving the use of arrays could
> be considered a 'rare case' or an 'outlier case'
To handle arrays better without requiring more lines of code, how about
making numberFormat itself an array with at least two parts? Similar to
the way the clipboardData has parts.
Using it without a key works exactly like before, by setting both parts, ie:
-- (assume i=binary 5 and starting format=default)
set numberformat to "0.0"
put "#" & i into a[i] --> a["5.0"] = "#5.0"
If you want just the regular strings formatted and not any array keys,
or vice versa, use the appropriate part:
set numberformat["text"] to "0.0"
put "#" & i into a[i] --> a["5"] = "#5.0"
(or)
set numberformat["keys"] to "0.0"
put "#" & i into a[i] --> a["5.0"] = "#5"
Pros: Array keys can be set independently of their contents or any other
text, but only one "set" statement required for most situations. Fully
backward compatible. Basic syntax is just as before, easy to learn and
sufficing for many (most?) tasks.
Cons: A bit more complex and less English-like when using the special
parts. It's a bit unusual to need to differentiate array keys from all
other text.
Also: You'll notice it can be confusing if you think i=5 binary and
expect a change, but it was actually already text. If we have to add +0
&"" stuff it's less intuitive. But that's a separate issue to consider,
outside this particular point.
Mark:
> 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.
Doing a simple job keeps it simple, and it does that job well. However,
it would be possible to have both the classic simplicity and more power,
by adding more optional symbols and rules.
-- (assume i=binary 5555)
set numberformat to "$#,##0.00"
put "Cost:" && i into x --> x = "Cost: $5,555.00"
BTW, I've worked with Excel number format a bit. Supporting it would be
an impressive product compatibility and even benefit some of my own
projects. However, that might be overkill for LC team and the user. (It
has 4 parts, to start with, and a learning curve of its own for advanced
features.)
A simpler route (based on ideas and techniques while doing SpreadLib and
other projects) would be to retain any text prefix and suffix outside
the # and 0 number portion of the representation, and also look for
commas and periods within the number. Bonus: allow smart period/comma
positions and a few other tricks. Maybe including a parenthesis anywhere
before the number portion = negatives in parentheses.
-- (assume i=binary 5555)
set numberformat to "#.##0,00 EUR"
put "Cost:" && i into x --> x = "Cost: 5.555,00 EUR"
-- (assume i=binary 5)
set numberformat to "$ (0.##)"
put "Cost:" && i into x --> x = "Cost: $ 5"
put "Cost:" && -i into x --> x = "Cost: $ (5)"
That should be backward compatible, except if existing code was reading
the numberformat to analyze it for decisions or settings. Should be able
to figure out a way around that.
(If I've proposed something that has been proposed before, sorry!)
Richard:
> 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.
That's true, very nice to have that option too!
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:
http://lists.runrev.com/mailman/listinfo/use-livecode
