Quantcast

Make numberFormat even better

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Make numberFormat even better

Mark Wieder via use-livecode
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
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Make numberFormat even better

Mark Wieder via use-livecode
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
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Make numberFormat even better

Mark Wieder via use-livecode
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 <
[hidden email]> 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
>  ____________________________________________________________________
>  [hidden email]                http://www.FourthWorld.com
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Loading...