require 5.6.0; # hoh's are ambiguous before 5.56
I can't think of any way in which hashes of hashes are ambiguous.
What are you talking about?
sub _least_key {
my %self = (@_);
shift @{[ sort { $a <=> $b } keys %self ]};
}
I think you mean (sort {$a <=> $b} keys %self)[0]).
There's no reason to give yourself the overhead of creating an
arrayref, then dereferencing it, then shifting it.
# NON EXPORTED METHODS
# EXPORTED METHODS
"Exported methods" is a contradiction. The terms you're looking for
are "private" and "public"; you're likely to confuse people if you use
"Exported foo" in a Perl context and you're not talking about
Exporter.pm.
bless $self; # dont need to return() it because bless returns a ref.
The real reason you don't need to return it is because
it's the last statement in a block. The fact that it's a reference is
completely irrelevant. (And then later you have a bunch of subs whose
last statement is 1; -- I'm not sure what to make of
that, especially in the context of this comment, and especially since
most of them are immediately following a print.)
$self -> {$in} -> {cr} -> (); # run it, its valid, we leave the code
+ ref
# to the hacker. however, rather than return, we implicitly retur
+n
# whatever the code they gave us returned for purposes of modular
+ity
You're making an artifical and incorrect distinction here.
Effectively, you're saying that return foo() at the end
of a sub is somehow different from foo() in the same
place; this is incorrect (and is the sort of thing that leads to
superstition). Using an implicit return is also hardly going to help
"modularity" more than an explicit return.
return undef unless defined $self{$input};
$input;
Replace these lines with "return defined $self{$input}", since that
does what you really meant. Note that this also fixes the bug where
$input is 0 and $self{0} is defined that would otherwise occur on this
line:
return undef unless $self -> verify( $in );
You mention the fact that 0 is a legitimate menu choice in the POD;
perhaps you'd written this bit earlier and forgot to change it.
In any case, the above line is much more cleanly written thus:
return unless defined $self{$in};
Calling verify is needless overhead, as it re-chomps the
input you've already chomped once and adds all the baggage of calling
a subroutine.
Note that verify here is not all bad. It allows you
to change the way input is verified in the future without having to
remember to change the program in several places.
I was almost done responding, but this caught my eye.
shift @{[ sort { $a <=> $b } keys %self ]};
shift @{[ sort { $b <=> $a } keys %self ]};
foreach my $item ( sort( { $a <=> $b } keys %self ) ) {
It is rather bloated to write menus with an object
If you're worried about bloat in your code, blaming it on an object is
inaccurate. Your list of possible inputs is fixed at object creation.
You should store it in a useful format, with something like this:
$self->{keys} = [ sort keys %{$self} ]But instead you sort over and over, being horribly
wasteful.
please see perldoc perlref for a description of why we want to
use +{ } instead of just { }. It isnt strictly necessary, but quote
"may break in the future."
Where is this quote from? I can't find it in 5.6.0's perlref.
hdp.
|