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@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 > ____________________________________________________________________ > 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 > -- 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." _______________________________________________ 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
