Re: Quick and (dirty?) menus for the console

[hdp]

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.