Make numberFormat even better

[Richard Gaskin]

Roland Huettmann wrote:

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

That does look very nice indeed.  If that formatting is factored in a 
way that would lend itself to a generalized behavior script for fields, 
and if Curry or Hugh were inclined to contribute some existing code it 
would help the project get a running start.


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

In more popular languages like Python or R, or pretty much any open 
source tool (among programming languages that would be nearly all of 
them), what we commonly see is one person with an itch to scratch writes 
a something to fit their needs, posts it to a code-sharing repository 
like Github, and others come along an augment it.  Over time it grows 
into an ever more mature, robust, general-purpose solution, but even out 
of the starting gate it's useful, and only gets better over time.

A small project of this scope wouldn't need hundreds of developers. I 
can't imagine more than half a dozen contributing to it.  Most of the 
coding could be done by one person in less than a day.

Where more eyeballs may be most useful would be in the design.  The 
property names need to make sense, and ideally there would be ways to 
use this for list columns in addition to individual fields, so we'd need 
to come up with a sensible way to handle that.

We'd probably want to ask ourselves if this should be a function or a 
property?

As a property it feels most natural, applying formatting specs to a 
given object.  But there are tradeoffs there, including being able to 
have only one behavior script applied to an object, and the issue with 
getProp and setProp being unreliable in any environment in which the 
lockMessages might be set to true.

As a function it would be far simpler to design, but would require the 
user to code for it, rather than having it be a property you set once 
and never need to think about it again.

There may be other options too.

And the choice of whether such a library be written in LC Script or LC 
Builder.  The latter offers direct support for documentation and 
Inspector options (though it would certainly be useful to see those 
options available for LC Script as well, though that's another discussion).

We could brainstorm those design aspects here and now if we want.


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

By design LC does not allow overriding built-in functions the way 
HyperCard used to.  When I asked Dr. Raney about this decision, he asked 
me to observe the execution speed difference between the two, and noted 
that his token table was kept very trim with this decision.  He also 
invited me to come up with a case in which it was truly necessary to 
override built-in functions as opposed to using a new name for the new 
function.  In all these years I couldn't come up with one.

So in short, I think a new name for new functionality may be best.


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

To be included in the LC install it needs to be good, and if implemented 
as a function it may perhaps eventually be included with the other 
handlers currently in the revCommon lib.

But that would require that it be field-tested, so early adopters would 
first use it as a library or behavior they download and install.

It may be that the engine team may later borrow some of the design from 
the scripted version for inclusion in the engine.  But until Mark 
Waddingham posts "Yes, we have time and will do that this week" we'll 
need to consider options that aren't dependent on the engine team.  And 
as Curry and Hugh have shown, these things can be done by a single 
person in script, valuable even as add-ons.


[I was tempted to write a rant about package managers here, about how 
every popular language has one and we don't, and the relationship 
between platform adoption and the ease with which one can find and use 
extensions.....but that's probably best left for another thread.]


 > 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"?

At the bottom of the "Contributing" page for the LC code base there are 
links to C++ style guides:
https://github.com/livecode/livecode/blob/develop/CONTRIBUTING.md

I don't know of such a guide for scripted contributions.  That would be 
a good addition if anyone here wants to work with Panos or someone else 
on the team to draft that.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com