Make numberFormat even better

[Mike Kerner]

Whenever we decide we're done with this, someone needs to send me the code
and I'll throw it up on github, since I'd like to have a central repo for
helpful code, especially since with git and levure we have a pretty easy
way of adding those modules to our projects.

On Wed, Apr 26, 2017 at 11:14 AM, Richard Gaskin via use-livecode <
use-livecode at lists.runrev.com> wrote:

> 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
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at 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."