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
____________________________________________________________________
ambassa...@fourthworld.com http://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
