Improve Script Variables

Idea created by disabled_davidthorp on Dec 28, 2015

    Script Variables ($ and $$ variables) are great.  Benefits:


    • They’re much faster than fields or any other storage because they’re temporarily stored in local memory only - they’re not like fields and so their values are never stored in the file itself - never transferred over the network, never written to or read from disk, etc.
    • They can be defined where they’re used (ie. usually in the Set Variable script step, in the script you want to use it in).  Before we had variables, if we wanted to store something temporarily a field had to be defined - elsewhere, in the Define Fields - to store it in first.



    But variables still have some issues:


    • A variable is referenced entirely by the text string we arbitrarily choose to use for its name.  Unlike fields, TO’s, functions, scripts, etc. that are referenced by internal ID.  If we change the name of a field/TO/custom function/etc. it is reflected and updated everywhere in the system, even in external files that use it.  If we change (or heaven forbid, mistype) a variable name anywhere, it’s hoses everything that uses it everywhere else.
    • Scope:  Script variables in FileMaker currently have only two scopes:  1. File-level.  Prefixed by $$, usually called “global” variable.  2. Script-level. Prefixed by $, often called “local” variable.  (There are also calculation-level variables.  No prefix.  Really only make sense with things like Let statements in a calculation.  This post isn’t concerned with those).  We need other scopes including window specific and application specific.  Possibly others?



    So I propose some changes to script variables, without losing the two benefits mentioned above.


    Firstly, change variables to be internally referenced by ID so that if I change one’s name the change reflects everywhere in the file - same way TO’s, fields, scripts, and so many other parts of filemaker are currently handled.  To do that...


    The Set Variable script step could behave like the Set Field script step. Instead of an arbitrary text field into which the variable name can be entered as text (with a $ or $$ in front of it), it could be more object-like, like fields are, where I can choose a variable name from a list in a dialog, just like fields.   But unlike fields, etc., I could still define a variable on the fly, in that same dialog.  So at the bottom, or top, of the list of variables to choose from there’s also a plus button that I can use to add another variable name to the list.  I refer to scope later in this post - it would be important that when viewing this list of variables it only show the variables that are relevant in the current scope.  Variables local only to other scripts would be meaningless here for example and shouldn't show.


    But that said, don’t take away the arbitrary option if we want.  There could also be a Set Variable by Name[] script step that works exactly the same way the Set Field by Name script step works.


    In that list of Variable names in a dialog, I could also assign scope to it there.  Instead of just naming it $ for local/script scope or $$ for “global” (ie. file) scope, there would be a popup menu of scopes to choose from including local (same as $), file specific (same as $$), window specific, and application specific (ie. truly global across all files).  Possibly others?  If we’re worried that two filemaker files/solutions open at once might interfere with each other then create some way of grouping files into “solutions” or “projects” and make the “truly global/application” variable solution/project specific at least - but that's an idea for another post I think.


    When referencing variables in calculations, these could work exactly like fields, TO’s, functions, etc. currently do:  I’d start typing its name into a calculation like I can a field/TO/function name and it finds it in the type-ahead menu thing that pops up currently.  And of course if the variable name is changed at its definition point, then that reflects everywhere, again, just like fields, TO’s, functions, etc.


    All that would be a great improvement to how variables are handled at the moment with the Set Variable script step and referencing variables.  Not only would it improve functionality, but using them would be very familiar, since we’re already doing everything these same ways with fields, TO’s, etc.  But…


    There’s two things the above doesn’t address, and that is:

    1. the ability to define $ and $$ variables on the fly inside a Let (…) statement in calculations
    2. the ability to define $ and $$ variables abstractly with evaluate statements - something like: 
      • Evaluate ( “Let ( $” & name & “ = ” & value & … & “ )” )



    At this point, I’m not entirely sure the answer to those, other than the following comments:

    Most of the time I’ve only ever used constructions like that to:

    1. help with managing multiple script parameters and results, or
    2. add namespacing to variables to try to simulate window level variable scope or something similar to that. 



    1. is solved if we just add native script parameters ( and results (,
    2. is solved if we add all possible scope options to variables as described above anyway.


    Needless to say, if there’s any other use for these techniques (I’m sure there is), then I see no reason not to simply continue to allow those types of calculations in *addition* to the scoping and internal referencing of variables I’ve proposed in this post. Or... does anyone else have any ideas on that one?