Make numberFormat even better

[Roland Huettmann]

Thank you, Richard, Curry, Mark...

It is a very nice approach that Curry already realized: and it is available:
http://curryk.com/ck-num-format.pngn better

But what I do not yet understand is how to make a joint effort with
hundreds of developers ))) available to ALL of us in practical terms --
seamlessly.

For any newbie and for those using formatting all the time, do we have to
load a separate library or would it be supported out of the IDE? For
example, could the numberFormat or format() functions be overwritten so
that simply using LiveCode Script it would work the way we defined and this
out of the engine?

Or is it a new function? And could it be shipped with the product if
approved? Again, we are thinking of Excel style formatting that any user,
even non-programmers, often enough know about.

And how can we contribute? Is it a joint effort where someone is delegating
the task? Or is it the work of someone taking the time to write it for ALL
of us? And, also I wrote about this, I feel a bit shy to think that I could
provide code that would or could really be seen as a viable contribution. I
do not know what really makes LiveCode Script be quality code?

Is there any guide telling that such LiveCode Script following certain
style and rules and using the best performant way will be accepted as
"quality code"?

I know about naming variables (naming conventions), and I assume that
comments could also follow style (comments disabling parts of code,
comments to the code, etc.), and even possibly assigning variable names
that are common to everybody -- for example, I have a style to always name
sames types of variables the same way: For example for variables containing
file information: tFileName (with extension), tFilePath (full absolute
path), tFolderPath (without ending slash), tShortFileName (without
extension), tFileExtension (just the extension), or i, j, k... as counters.
Because I am lazy, I find such conventions (for private use, or for
community use) very helpful. I assume there are 30-50 standardized names
that could be shared to make code easily readable and that also newbies
should know about.

Then, again to be practical, how would we name fields and how would we name
custom properties indicating how code should work with a field and format
such field?

Assumed, there is a currency style field with a format such as
"$#,###.00":=  "$1,000.00" where a style property would be set for this
field. This field also serves as a database field and should "know" to
which data source it is connected and also may know in which order database
fields appear. That is another custom property. So, a command saving to the
database would look up all such fields, convert strings to numbers the
database understands, already know the underlying database field name
without any further scripting, and simply saves whatever is there. And,
yes, there is a behavior script assigned to such field - and it depends
whether data is entered manually, or it is put into the field through a
script.

Another field could present a scientific notation and accept and display
scientific notations.

This can grow to become a very dynamic behavior when strictly following a
certain style that is used by everybody.

Or am I thinking into the wrong direction?

I am not worrying doing it for myself. I am more thinking when we are
offering this as an adopted standard.

With dates, there is always a problem in Central Europe because the system
date displays a date string that is not seen by the engine to be a date. It
is NOT a date for LiveCode Script. Here, we have DD/MM/YYY or DD.MM.YYYY.
So, I must always convert such date anyway to allow LiveCode testing it to
be a valid date. For SQLite and other databases we need it to be
"YYYY-MM-DD" and internally we might just use the seconds.

Then, adding field "A" of type date to field "B" of type date (or
variables/arrays representing such fields) should result in a new date
without even having to think.

And I assume it would be best for users setting the field format using a
context menu clicking on the field in questions and setting such behavior
and formatting options -- if this is not part of the Property Inspector.
Such context menu could open some Settings pane when needed.

Or can we, should we, simple users, modify the Property Inspector?

I assume it would be best if someone following the guides and with deep
experience would implement while the rest of us could contribute with
testing, discussing, etc. ?

And because of all this, and for joint work especially, I would really
appreciate more standards, more guides for "best practice", even strict
rules -- not to make things not work when breaking such rules, but to make
things easier and more transparent in the other 99% of cases.

Roland