Re: The default hash - accident, coincidence or conspiracy?
by merlyn (Sage) on Jun 20, 2005 at 11:53 UTC
|
| [reply] |
Re: The default hash - accident, coincidence or conspiracy?
by ysth (Canon) on Jun 20, 2005 at 11:55 UTC
|
From your example, I'm not sure what you see that is special about %_. Perhaps just that you don't have to declare it with our/use vars when under stricture?
You should be aware that there is something special about it, though. Just like $_ and @_, if you use it without a package qualifier such as %Foo::_, it references %main::_, not the current package. IIRC, this is indeed documented. | [reply] |
Re: The default hash - accident, coincidence or conspiracy?
by ank (Scribe) on Jun 20, 2005 at 11:58 UTC
|
Even though there is currently no special use attached to %_, I would stay away from using it - it can only confuse other programmers when they see $_{$key} or some variation of that.
| [reply] |
|
That's an argument against the entire Perl language, so I have to disagree.
As long as one understands the special globality of the name (as pointed out in several other replies),
one should no more avoid %_ than $_ or @_ — or, for that matter, any of the other funky globals.
| [reply] |
|
Well, maybe that's an argument against the entire Perl 5 language. One should also understand that the "special globality" of the special variables is going away in Perl 6, so something like %_ is going to become lexically scoped rather than globally scoped. So the p5-to-p6 translator is going to have to turn any Perl 6 use of %_ into something like %*_ to make sure the name stays global. Or if we're spiteful enough, it'll turn into %*_P5_EMULATED_GLOBAL_UNDERSCORE_PLEASE_AVOID_ or some such... :-)
Similar considerations apply to many of the other special variables that need to be rehung on filehandle objects or lexical scopes. And some of the special variables are simply going away, and will have to be emulated by the translator some other way.
So when people are tempted to rely on idiosyncracies of the Perl 5 implementation, I would remind them of this comment of Henry Spencer's from regexp.h:
regnode program[1]; /* Unwarranted chumminess with compiler. */
| [reply] [d/l] [select] |
|
I don't see how that is an argument against the Perl language - just because you can do something in a certain way doesn't mean that it's desirable to do so.
As a general rule, I try to avoid potentially confusing code whenever possible. Remember: a good programmer is someone who looks both ways before crossing a one way street.
| [reply] |
Re: The default hash - accident, coincidence or conspiracy?
by tlm (Prior) on Jun 20, 2005 at 12:34 UTC
|
| [reply] |
Re: The default hash - accident, coincidence or conspiracy?
by Animator (Hermit) on Jun 20, 2005 at 12:03 UTC
|
The question should not be 'will it be supported', the question should be: 'do you want to use it'?
It's a real global variable, it lives in the main/default symbol table, you can not lexicalize it, and more important, every file and package can modify it.
Especially the last point will make it hard to maintain and/or modify and/or integrate it with other programs.
This is ofcourse all true for $_ and @_, but do you really rely on them having a certain value? I certainly do not.
Also note that there is no point to have a 'default' hash. You can create a package-global hash (%config for example) which you can access from other packages by including the package name. And if you are not happy with that then you can even import it in other packages.
| [reply] [d/l] [select] |
|
Thank you all for such prompt response -- already Animator's point about it being open to modification by any module has persuaded me (sigh) not to use it - pity in a way - it looked so inviting. (-S)
| [reply] |
Re: The default hash - accident, coincidence or conspiracy?
by tlm (Prior) on Jun 20, 2005 at 11:58 UTC
|
FWIW, I have seen CPAN modules use %_, though right off the bat I can't remember which. My point is that you can't assume it is free for the taking.
Personally, I'd stay away from using variables corresponding to unused slots of special variable globs. It's asking for trouble, IMO.
| [reply] |
|
It is free for the using, if not taking. The local keyword is there to facilitate multiple code chunks using the same global variable independently. It works well enough for $_ and @_, it will work just as well for %_. (That's not to say it's a panacea, though.)
I don't understand why people think it's asking for trouble. It is no more asking for trouble than using $_ — and I sure wouldn't counsel anyone to avoid using $_. Quite the opposite, in fact.
That being said, there isn't any really good reason to use %_. The situations in which it would be the most obvious, "natural" name for a variable must be rare indeed.
| [reply] [d/l] |
|
I don't understand why people think it's asking for trouble.
IMO, using package variables in one's code, in general, is asking for trouble (though there may be situations in which one is willing to accept this trouble). Moreover, as I pointed out, some module authors have had the bright idea of using variables such as %_, so one can't be sure that these variables are completely available, and that the other code that uses it is being good about using local whenever it uses the same variables. IMO, having to even worry about these things falls into the category of "trouble." The fact that the docs specifically state that the variables the OP asked about are reserved for Perl's use makes it all the more troublesome to use them.
| [reply] |
|
|
Re: The default hash - accident, coincidence or conspiracy?
by dragonchild (Archbishop) on Jun 20, 2005 at 12:32 UTC
|
Use a singleton. Class::Singleton is a good place to start. Anything that is global cannot, by definition, be the perfect alternative to global ids to store such information in a predefined data dictionary.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |
Re: The default hash - accident, coincidence or conspiracy?
by ank (Scribe) on Jun 20, 2005 at 19:23 UTC
|
As an interesting side note, there's a bit on the Perl source code that uses %_ (as part of the obfuscated language tests.) Namely, take a look at: t/japh/abigail.t
For instance:
$" = "/"; split // => eval join "+" => 1 .. 7;
*{"@_"} = sub {foreach (sort keys %_) {print "$_ $_{$_} "}};
%_ = (Just => another => Perl => Hacker); &{%_};
| [reply] [d/l] |
Re: The default hash - accident, coincidence or conspiracy?
by GrandFather (Saint) on Jun 20, 2005 at 20:43 UTC
|
use strict;
use warnings;
%_ = ( a => 1, b => 2 );
print $_ {"a"};
does not generate any errors or warnings. Maybe that was what OP meant by "predefined"?
Perl is Huffman encoded by design.
| [reply] [d/l] |
Re: The default hash - accident, coincidence or conspiracy?
by kaif (Friar) on Jun 21, 2005 at 01:12 UTC
|
sub foo { # takes a hash argument
my %_ = @_;
}
and discovered that that doesn't work. Later, I thought "of course" (because of typeglobs!) and used local %_ instead. Although the presence of "the same" %_ regardless of package may be a problem, as mentioned above, maintaining this should be no more difficult than similar code using $_ and @_. | [reply] [d/l] [select] |
A reply falls below the community's threshold of quality. You may see it by logging in. |