Re^7: VarStructor 1.0

[tkil]

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.

[Wassercrats]

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."

[tkil]

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.

[Wassercrats]

Yes, it's open to criticism, but when that's ALL I get, I have to point out some of the script's worth.

...all the active variables are local to the current subroutine. Any longer-lived values live in a very very few globals...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...

When I say global, I mean not "my". cgi.pm contains 15 globals, and I don't consider 15 to be "very very few."

I'll go out on a limb and say that a talented and experienced programmer would get the job done faster if he didn't use strict, assuming he learned that way or has an equal amount of experience both ways. Warnings would sometimes help and sometimes slow you down. Localized variables would sometimes prevent conflicts with imported variables, but aside from that, they're just novelties to me that pollute scripts with "my"s.