J. Landman Gay wrote:
Richard Gaskin wrote:
So given the freedom of not using explicitVars while fleshing out
algorithms, is it really a valuable thing and I'm just lazy?
For the record, I don't like explicitVars because:
<snip - some good reasons omitted>
In particular, I agree with J's comment about the bloating of scripts
with extra lines that make it harder to see the wood for the trees. But
I do want to retain the benefits that I see in detecting typos and
similar errors.
So here is an initial proposal for something I'm thinking of as
"implicitVars". Don't focus on the part where I'm lazy and describe it
in implementation terms - focus on the intended 'experience' for the
end-user (i.e. scripter).
When implicitVars is enabled, the script parser does the same task of
detecting undeclared variables as it currently does for explicitVars.
However, when such an undeclared variable is found, the parser checks
the list of 'implicitly' declared variables for the current handler.
If the variable is in this set of 'implicit' variables, then there is
naturally no error. If the variable is not in the 'implicit' set of
variables, then an error dialog is presented to the user; the user can
choose to respond by either
- adding this variable to the list (i.e. the implicit list)
or
- exiting to the script editor (e.g. to declare it, or to fix a
typo, or ....)
Each handler therefore must have stored with it a set of implicitly
declared variables; this list of variable names does *not* appear in the
script itself. (Maybe it is stored as a custom property of the
script/handler, or something like that - therefore it could be viewed,
and even modified by the user - or by the script editor or add-ons to
the editor).
This gives the advantage of a short, clean, easy-to-read script while
preserving the advantage of error detection. The need to respond to such
a dialog once per local variable would be (at least for me) a small
price to pay - and is certainly much lighter a burden than the need to
add a declaration for each.
--
Alex Tweedly mailto:[EMAIL PROTECTED] www.tweedly.net
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
