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?
Sorry I'm late to the party, but Ive been busy - and I would like to
speak up in support of explicitVars. In fact, I have two answers to give
- a quick 'blow-by-blow' response to these points, and then (in a
separate email) a serious (even if not yet fully thought through)
proposal for an improvement (called, for the moment, "implicitVars")
For the record, I don't like explicitVars because:
1. The main strength of xtalk is that you do not have to declare or
type variables. Sticking them up there at the top of every handler
removes one of the main advantages of using Rev in the first place.
"main advantages" - surely not. Even if it is an advantage, this can't
be a "main" one, can it ?
2. You can't comment out a long handler using a single set of hyphens
before the "on" statement. (I often write multiple versions of
handlers and switch between them.) As soon as you do that, all those
"local" declarations become script locals and everything goes haywire.
You have to comment out all of the declarations. If they aren't all at
the top, you have to comment out the whole handler. That's more work
than it needs to be if you're going back and forth between a few
copies to see which one works best.
That means not only do you not use explicitVars and declare all
variables - you don't declare any (local) variables. That seems to me a
non-robust practice - especially if you share code written by others, or
use their code; having just a few variables that were for some reason
declared become script-local could lead to very hard-to-find bugs.
Also, as keen user of colorization in scripts, I like to have the color
properly represent the status of the lines of script and this habit of
disabling a handler without having it properly become a comment disturbs
the value of colorization.
Far better, surely, to have support for enabling/disabling a handler
either in the language or in the script editor.
3. It looks busy and it makes scripts denser and more complicated than
necessary. I've seen handlers where the declarations can take up
almost as much room as the code. It's hard to read other people's
scripts if they use explicitVars because you have to skip over so much
junk to get to the real business. In large projects it can add
significantly to the file size on disk.
file size on disk ? what decade is this :-) ?
It's uncommon (I contend) for real scripts to have the number of lines
of declaration be as much as 10% of the number of lines in a handler -
insignificant compared to Rev's habit of storing both raw and formatted
version of the script.
But I do agree it can make the script denser, longer and harder to read
- see my proposal for implicitVars.
4. If you change a variable name, you have to go back and change the
declaration. It's more work to maintain, for something that isn't even
required by the engine. (I have wondered if people sometimes do it to
make their code look more like "real" programming to other people.)
Who cares about the engine - I care about the readability of the script,
and the ease of early detection of bugs. If you change the name of a
variable that should (??) imply change of intent or purpose for that
variable - which means to me that it isn't a bad thing to
examine/consider each usage of the variable - so explicitVars is pretty
helpful in finding them.
5. And finally, what's wrong with being lazy? :) The smart programmer
finds the easiest way to do things. That's what Rev is all about.
Nothing, intrinsically. But the smart programmer should find the best
way, not the easiest :-)
None of these things is outweighed for me by the fact that
explicitVars might catch a few typos. The engine catches most of those
anyway and throws an error.
I don't find that the engine finds most of them - but I may make fzr
mpre tipos then must poeplr di.
;-)
--
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
