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?

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
[download]

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.
[download]

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');
[download]

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
[download]

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.

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};
    }
}
[download]