This is an archived low-energy page for bots and other anonmyous visitors.
Please sign up if you are a human and want to interact.
in reply to Re^5: VarStructor 1.0
in thread VarStructor 1.0
Even with code where I disagree with both the style and the purpose (nicely done! :), I can still enjoy trying to figure out what is going on.
I keep forgetting to look into whether alternative methods of listing variables list the values as well, but I do know that when I used Xref at the command line, it gave me a laundry list of stuff that I didn't care about. There's no post-processing necessary for VarStructor to give you the user defined variables and values, and it's faster, easier to use, and more flexible than Xref.
I don't know how anyone could say that the addition of a reset feature that's more flexible and safer than Perl's not-yet-deprecated reset function is a bad addition, but you can't deny that listing variables and their values is useful.
The fact that your module exhibits exactly those problems that it tries to fix / support is what has made many of the exchanges here so painful.
My subroutine doesn't try to fix anything. It succeeds in being a tool to be used the way any module or Perl function is used. I'm using it because it's the best way to do what I have to do, and I won't settle for second-best just because others prefer it. |
Re^7: VarStructor 1.0
by tkil (Monk) on May 12, 2004 at 22:59 UTC
|
I keep forgetting to look into whether alternative
methods of listing variables
And you continue to ignore the fact that we are advocating
a programming style where you never have to do massive
lists of variables, because all the active variables are
local to the current subroutine. Any longer-lived values
live in a very very few globals, or in objects that can
operate on their own contents.
I don't know how anyone could say that the addition
of a reset feature that's more flexible and safer
than Perl's not-yet-deprecated reset
function is a bad addition,
We're not saying that such an addition would be bad.
We're saying that such an addition has already been
made, and its name is my. Variables so
declared are "reset" at the end of the block, with no
additional code needed! Magic!
We see you driving around an old jalopy that's leaking
oil and basically being a mainenance nightmare. Doesn't
matter whether you wrote it, or if you just inherited it.
We are suggesting that you fix the car; you keep on
wanting to build a bigger and better tow truck.
As before, I wish you luck. Especially because, with
this programming style and development mindset, you are
going to need it.
| [reply]
[d/l]
[select] |
|
|
I counted 15 globals just at the top of cgi.pl, where it says "# >>>>> Here are some globals that you might want to adjust <<<<<<" which makes sense because you would want all the user-configurable stuff together, at the top of the script, no matter what subroutine they get used in. Whoever wrote CGI.pm surely knew how my variables work because he used them, but he didn't think it was practical to make the user defined variables local. Everyone's programming habits are different, and there are some much longer programs than cgi.pm, even though it's one of the longest modules. I don't think it would be too difficult to find a script with much more than 15 globals.
Everyone seems to be picking on the cosmetic things or the things they wouldn't need. Remember, along with the values, you get the variable names, which someone decided is useful since they're provided by Xref.
It's impossible for anyone to say that a script is a maintenance nightmare just because it uses all globals, no warnings and no strict. My script requires fewer hops to different subroutines, which could make it an easier read. Thinking up unique variable names is easy, and searching the script just in case is easy too. Well written comments within the script and on top are a big help. I have well defined "blocks" of code, but I don't have to bother passing local variables around. They're always exactly where I want them. I don't have the problems described here either.
Not only is my 3400 line script not a maintenance nightmare, but it has fewer bugs and works better than many production scripts I've seen, including its future competition.
EDIT... Forgot to mention another benefit of VarStructor. It could help you be sure that your variables are "my" variables. If it shows a value, you know you forgot "my."
| [reply] |
|
|
Whoever wrote CGI.pm surely knew how my variables work
because he used them, but he didn't think it was
practical to make the user defined variables local.
I never said anything otherwise. In fact, I follow this
same style myself: at the top of my programs, there are
typically some global variables (my, but
still treated as globally available) that control
behavior of the rest of the program. I think this is
healthy, and (among other things) promotes an eventual
migration to using options or other more advanced ways
of setting user preferences.
Everyone seems to be picking on the cosmetic things
or the things they wouldn't need. Remember, along
with the values, you get the variable names, which
someone decided is useful since they're provided by
Xref.
I addressed this obliquely before, but: there is an
implicit assumption here on perlmonks that any code
posted is open for criticism. In this case, we first
criticized its higher-level "in the large"
function: supporting a coding
style that we find painful and distasteful. When you
said that you were stuck with (or were going to stand
by) that coding style, I took it upon myself to address
some of the "in the small" deficiencies. Now you
complain that we're nitpicking.
Which leaves us in the same position as has shown up
a few times already: if you didn't want criticism, then
explicitly say so. If you do post something that way,
though, don't expect us to endorse it for enclusion into
CPAN or even as a node that should survive here on
perlmonks.
It's impossible for anyone to say that a script is a
maintenance nightmare just because it uses all globals,
no warnings and no strict.
No, but it is entirely possible to say that in one's
experience, scripts that use strict,
use warnings (or the older -w),
and minimal globals are easier to maintain, modify,
and debug. So, when confronted with a script written
in a style which avoids all these programming aids (make
no mistake, that is how the majority of monks perceive
them), we are justified in guessing that this script will
be more of a pain in the ass than most.
Forgot to mention another benefit of VarStructor. It
could help you be sure that your variables are "my"
variables.
Funny, but that's one of the things that
use strict does for me.
| [reply]
[d/l]
[select] |
|
|
|
|
|
|
|
