Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

VarStructor 1.0

by Wassercrats
on Apr 30, 2004 at 19:58 UTC ( #349496=sourcecode: print w/ replies, xml ) Need Help??

Category: Utility Scripts
Author/Contact Info barry@polisource.com
Description:

Alternative to Perl's reset function, with extra features. Also could be used to print variables and their values, including "my" variables. See top comments in script.

I'll probably add an option to exclude the "my" variables, and I intend to make this into a Cpan module (it's currently in subroutine form).

This is an improved version of VarStructor.

Code removed by author. I no longer want to contribute to this community.

Comment on VarStructor 1.0
Re: VarStructor 1.0
by diotalevi (Canon) on Apr 30, 2004 at 20:59 UTC
    I would sincerely ask you to not upload this to CPAN. While there is no enforced minimum standard of quality for code there or here, this goes particularly low and really should not be shared with a wider audience.
      That's the second comment like that that I got (well, first for this version). Both with no explaination. I'll ignore it.

        I will attempt to recap my conversation with you about these matters after the May weekend has concluded. Be sure, I did talk with you about this in the chatterbox at least twice. I will quickly note that you are using globals in an unsafe manner, system calls without checking for failure, and parsing perl. I recall raising more issues but I don't recall them at the moment.

        Oh yes. It was also a disagreement with the purpose of the code. reset() is something meant more for perl4 code where we didn't have my(). Common best (or even mediocre to poor) practice uses my() to properly handle the issues you are attempting to handle by continuing in the perl4 idiom.

Re: VarStructor 1.0
by Wassercrats on May 01, 2004 at 18:54 UTC

    VarStructor 1.0 actually has more negative votes than VarStructor, which was way less complete and had a bug (which was never mentioned by anyone).

    The voting system is a joke.

      The voting system is a joke

      Actually, the voting system is a feeling of the Monastery about the proposed node. It is not intended to be perfect, but for the ones who can listen, it's a good device.

      Your problem is that you don't listen.

      This previous node was downvoted just because it was a bad idea.

      This one was downvoted more because:

      • It is still a bad idea
      • Despite being told not to do it, you insist on wanting to publish it to CPAN.
      • When people explains to you what was wrong with your code, you again don't listen.

      Basically, the situation is as follows: you come here and publish your code. This is an implicit request for feedback. People offer you feedback, saying that your code is bad. Instead of listening to the sound advice, you criticize the very system that you wanted advice from. How could you possibly be surprised if you are downvoted? Grow up!

        Please be more specific.
Re: VarStructor 1.0
by Wassercrats on May 02, 2004 at 08:09 UTC
    Guess I should mention that I replaced the old VarStructor 1.0 in the original post with the latest version. I just fixed bugs that I found myself, so I don't think anyone would be confused anyway.

    I'm not going to bother upping the version number.

      Hi Barry,

      From my point of view, it seems that you aren't getting how this community works.

      The name of this place is The Monastery. It's supposed to be a calm, cool, quiet oasis of learning and understanding.

      Once written, a node should be updated, not replaced wholesale, since that invalidates any followup nodes to the original post. Note changing the version number is particularly unhelpful -- what if someone were following your code? "Gee, this script looks different -- but it has the same version number -- oh wait, he changed the code but didn't change the version number. Wonder why he did that?"

      Yes, the voting system seems a little cruel sometimes -- treat it like community feedback. If you get a few ++'s or --'s, that's OK. If you get lots of ++'s, you've written something pretty darn good. And if you get lots of --'s, your post was rotten.

      Instead of flaming the useful feedback you get from your post, gratefully acknowledge it in the spirit it was given, and perhaps post again.

      Spend time to carefully write your creation, enough time that you have covered the 'or die' error scenarios. Certainly, some web sites have very good uptime records, but the 'or die' is not useful when everything works well, but, like seatbelts, they will save you when something goes wrong.

      Alex / talexb / Toronto

      Life is short: get busy!

Re: VarStructor 1.0
by tkil (Monk) on May 04, 2004 at 08:34 UTC

    Ok. Here is what I have so far; this is the result of about six hours work on your utility, trying to keep track of why I changed things the way I did.

    I still don't think that this particular library is all that useful, and I agree with many of the other monks that it violates good coding guidelines left and right. It works for you, and I have no problems with that; the question is, would it work for other people?

    The guidelines we put in place are not there to be memorized and followed by rote; there are more than a few debates about the finer points. But the overall goal is to make programming easier, less haphazard, more fun, and more reliable. Many languages and years of experience have shown that encapsulation, decoupling, data hiding, orthogonality, commenting, code-reuse, and not trying to outwit the language are all likely to make your life as a programmer more rewarding and productive. And I know that you do not consider yourself a professional or career programmer -- isn't it all the more important that you don't waste time and effort going down the same dead ends and roundabouts that others documented years ago?

    Here's my list of points you might want to think about when you write code:

    And here is my rework of the code so far. (This is version 15 in my local version control; I've been trying to keep different changes isolated. I can try to publish the entire sequence one way or another, if you're curious what sort of changes I've been making as "chunks").

      I agree with all this pretty much. I have to admit I wonder at wassercrats thinking on occassion. He doesnt seem to learn when the mule kicks other people, and its not even clear if he learns when the mule kicks him. I dont get this at all. Most people I know learn from other peoples mistakes. *shrug* Its his life I guess.

      But I do have a nit: You said ^ (and, for that matter, $) are not special inside of character classes. which is wrong. ^ is special inside of char classes when the it is the first character of the char class. It cause the char class to be negated.


      ---
      demerphq

        First they ignore you, then they laugh at you, then they fight you, then you win.
        -- Gandhi


        ^ is special inside of char classes when the it is the first character of the char class. It cause the char class to be negated.

        D'oh. Perfectly true, of course. Where's my brown paper bag?

Re: VarStructor 1.0
by Steve_p (Priest) on May 07, 2004 at 15:22 UTC

    After seeing all the negative comments and downvotes on this node, I thought I had finally seen the end of it. Unfortunately, the verbal combat regarding this node has spread elsewhere in the Monestary. However, one comment caught my eye. The claim that only one bug had been found amazed me. "Could that code only have one bug?" I thought to myself. So, I decided that I would clear my head of the other comments and the invective that has surrounded this node and take an objective look at the code.

    The first thing that troubles me is that use strict and use warnings is no where to be seen. Was this an error of ommission in the paste? So, I took the code from the node and ran it with just warnings. Already, the one bug had been joined by two more. Here's the output.

    Name "main::Simple_Arr" used only once: possible typo at VARSTRUCTOR.p +l line 15. Name "main::Simple_Var" used only once: possible typo at VARSTRUCTOR.p +l line 14. Name "main::hash1" used only once: possible typo at VARSTRUCTOR.pl lin +e 11. Use of uninitialized value in pattern match (m//) at VARSTRUCTOR.pl li +ne 66. Use of uninitialized value in concatenation (.) or string at VARSTRUCT +OR.pl line 111. $Simple_Var = simple @Simple_Arr = simple1 simple2 %hash1 key1=value1 key2=value2 %hash2 key1=value1 key2=value2

    The first three warnings are bogus since that's simply how the program works. The next two warnings are a question to me. Are the real errors or should the program be checking for undef in a few extra places. Anyway, since most programmers consider warning free code to be essential, I'll consider these to be bugs. This took me about 2 minutes to find these two bugs.

    I thought for a moment now about adding use strict, but since there are no mys anywhere in the program, I thought I save this for now.

    The next big issue I noticed was that of style. All languages have a certain style that is generally accepted within the code. Perl is not an exception to that. Some of the style issues include: all uppercased function and variable names (typically these are all lowercase and constants are the only items that are all uppercased); lack of Pod for documentation; documenting the functionality of a function inside of it (this is typically done separately); quoting variables on assignment (i.e. $Targ = "$_[2]";) is unnecessary; there are scalars and arrays with the exact same name with the difference being the "$" and "@"; it doesn't use warnings; it doesn't use strict; it doesn't use my; and, comments and code go off the right hand side of the screen. On there own, these would be turn offs to your code. Together, it invokes rather violent reactions in people.

    Now, that that's over with, a look at the functionality is in order. So, I turn to the comments. The comments are not the greatest, but I finally understood what the function was supposed to do. What concered me then was the API of the function. This function has two rather distinct sets of functionality based on parameters passed into the function. My suggestion is rather than changing the functionality based on a parameter is instead have two separate functions. The code with then be much cleaner and easier to understand so that the " if $Function =~ /^clear$/i and  if $Function =~ /^show$/i are not required throughout the code. The bigger question I have regarding the show functionality is what's wrong with Data::Dumper. The show functionality does something similar but the API to do it stinks.

    So, now, I did what I put off at the start. I added use strict and added my to the variables. I did run into the while loop that had comments in the middle of the conditions. That annoyed me a lot. Finally, I got mys in front of all the variables. So, I ran the program, and...

    syntax error at VARSTRUCTOR.pl line 12, near "$hash2{" Execution of VARSTRUCTOR.pl aborted due to compilation errors.

    So, I looked at the code and realized that%hash2 had values being assigned to it before being declared. So, I changed the start to

    my %hash1=("key1"=>"value1","key2"=>"value2"); my %hash2 = (); $hash2{"key1"}="value1"; $hash2{"key2"}="value2"; my $Simple_Var = 'simple'; my @Simple_Arr = ('simple1','simple2');

    and ran again. Here's the new output is...

    Use of uninitialized value in pattern match (m//) at VARSTRUCTOR.pl li +ne 67. Use of uninitialized value in concatenation (.) or string at VARSTRUCT +OR.pl line 116. $Simple_Var = simple @Simple_Arr = simple1 simple2

    Now, %hash1 and %hash2 are not displayed. More bugs. My guess is that the Regexp that extracts the hashes doesn't like my very well, but that's only a guess.

    Now, here's my parting opinon. reset is deprecated because using my and limiting the scope of your variables makes for better programs. The code above one entrenches my belief that use strict and use warnings makes your code more robust than without it. As far as the coding style, this is the kind of code that gives Perl a bad name. It follows almost no traditional coding style. Its API is barely comprehensible. The "show" functionality looks at values of variables as they are declared, not point in time making it nearly useless if your variables are passed to functions. So, in conclusion, I see no use for this code if you make use of current coding standards and use Data::Dumper. It also has a few bugs that may cause this to work incorrectly.

      ...Anyway, since most programmers consider warning free code to be essential, I'll consider these to be bugs. This took me about 2 minutes to find these two bugs.

      ...

      The next big issue I noticed was that of style...

      Thanks for that, and the complaints about the other bugs you found after you spent needless time trying to correct those "bugs". Your response is the perfect representation of most of the others. I might include it in the documentation of the module as an example of the reason people might give bad reviews to my code. You've apparently included the "use lame" pragma in that post.

Re: VarStructor 1.0
by rir (Vicar) on Jun 04, 2004 at 02:47 UTC
    I read your post far enough to realize you were ostensibly writing a replacement for reset. Though I have used Perl since PERL days I had no idea what reset did. Looking it up, I wrote the following.

    Coming back to look at your code I realize your code has little to do with reset. It is not clear to me what you want your code to do, but rather than try to find your program and parse it, I would suggest you might walk the symbol table and read scratchpads if need be.

    Be well.

    sub r_reset { # This routine emulates the Perl CORE reset function # which is deprecated. It does not work without an # argument as ?? ops are also deprecated. die "Wrong args to r_reset" unless 1 == @_; my $chr = shift; die "Invalid characters in arg to r_reset" unless $chr =~ /^[-\w]+$/; die "Uppercase characters in arg to r_reset" if $chr =~ /[A-Z]/; my $pkg = caller(); no strict 'refs'; foreach my $var (grep /^[$chr]/, keys %{"$pkg" ."::"}){ undef ${$pkg . '::' . $var}; undef @{$pkg . '::' . $var}; undef %{$pkg . '::' . $var}; } }
Re: VarStructor 1.0
by Wassercrats on Sep 01, 2004 at 18:58 UTC
    (I'm reviving this thread in response to Re^5: Perl 6 ... dead? (no, just convalescing) .)

    What if you were maintaining someone else's 3000 line script that used all globals and you wanted to serve the script over and over as a web app? You might find they need to be reset before each iteration of the script. How would you would handle resetting variables without VarStructor? Would you "walk the symbol table" and rebuild my solution even if mine runs faster, is easier, and works for the script? Would you spend countless hours rewriting the code? If it were your script and you were a "good" programmer and only used the occasional global, you could find yourself in the same situation.

    Sometimes a global is the best choice of variable. You could use the extremely flexible variable listing functionality of VarStructor to identify the variables and hard code a reset ($var = ''), or you could use the equally flexible reset feature (which is more flexible and safer than Perl's reset function) for an easier but slightly slower-running solution.

      How would you would handle resetting variables without VarStructor?

      By refactoring the code for sanity.

      Only a big ball of mud has so many globals that resetting them manually is an error-prone task. And that's just a corollary of the fact that everything in such a codebase is an error-prone task.

      Makeshifts last the longest.

        That falls into the "countless hours rewriting the code" category. Resetting the variables manually is error-prone when the script is large, but it's mostly just time consuming, unless you have VarStructor. It doesn't indicate a big ball of mud, and you don't know how I structure my script, what comments I have, and what other supporting material there is. And it works.

Back to Code Catacombs

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: sourcecode [id://349496]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (8)
As of 2014-07-25 02:15 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (167 votes), past polls