• our()
• open(my $foo)
• open(my $foo, ">", $file)
• warn() && exit() inside a BEGIN without complaining about compilation errors

I'm sure there's more. It's been so long since I used 5.005 that I've probably forgotten a lot of the worst stuff.

-sam

Hmmm, very true. Why didn't I think of that? So looking at Perl 5.6 delta

Some highlights you didn't mention:

• Better threads (but superceded by 5.8 threads)
• Better subroutine attributes
• 3 arg open (you touched on it above)
• CHECK blocks
• lvalue subs
• Improvements in subroutine calling speed
The 3 arg open looks very useful for more concise code. Code speedups are always nice. :-) What are CHECK blocks? Piers Cawley (through Google) tells me that:

So, what's a CHECK block? The idea is that they're supposed to be called after compilation is completed. They're intended to be used by the compiler backends, to save the program state once everything's been assembled into an op tree. However, there's no reason why you can't use them for other things instead.

Anyone come up with a use for a CHECK block other than a backend compiler writer?

So what about lvalue subs? When would they be useful? IIRC, they simply mean you can do my_sub() = 'foo'. But I've never run into a situation where this would be useful.

And finally, what about attributes? I've been looking at Maypole and it uses attributes to mark methods callable sub method_name :Exportable { } via the URL ("/appbase/table/edit/id"). Any pointers to good documentation about attributes and how they can make life better?

Some highlights you didn't mention:

Yeah, I don't use any of those! Threads in Perl are fun to play with but hardly production-ready. Attributes and lvalue subs are sugar I don't seem to need.

-sam

Can you explain why you find our indispensable?

To understand my existing preconceptions, see Why is 'our' good?.

I find 'use vars qw()' to be hard on the fingers and even harder on the eyes, particulary as a twin to the very pretty my(). I use our() at the package scope where I'd otherwise 'use vars qw()', basically.

I've played with using it to scope access to global data in shortish scripts, but I didn't find it all that useful.

-sam

• use warnings. Being able to do proper lexical scoping with your warnings is very nice.
• Large files. Very important if you ever need to work with a file larger than 2 GB (you will need this at some point)
• 64-bit support. You can get this either if your processor supports it or if your C compiler can fake it (of course, it's not as fast on 32-bit archs)
• POSIX character classes. I don't use these often, but when I do, I'm glad I have them, as the simple character classes Perl has always provided are sometimes not quite enough
• our. There is a little controversy around this vs. use vars, and in general it's better to use my over either of those, but there it is
• qr. Kill off messy /o regex modifiers forever

Most of these came in 5.6.x. If you're going to upgrade from 5.005, you might as well go all the way to 5.8.

I'm pretty sure qr was introduced with 5.005, if not earlier.

autarch@houseabsolute:~$ perl5.00503 -le 'print qr/foo/'
(?-xism:foo)

I'm using this in production so qr// is definitely valid in 5.005.

I'm definitely upgrading all the way to the latest stable. :-) I just got 5.8.3 installed on my test box at home, and it looks like I'll be installing 5.8.4 within the month. By the time $work gets around to upgrading we might even be at 5.8.5. :-)

• Weak references. Ever had interdependent objects? Perl 5.005:

  package A;
  sub new { 
    my $class = shift;
    my $this = bless {}, $class;
    $this->{-twin} = new B(-twin => $this);
    return $this;
  }
  package B;
  sub new {
    my $class = shift;
    bless {@_}, $class;
  }
  $obj = new A;
  undef $obj;
  [download]

  The A object formerly referenced by $obj will not go away until the program exits, even after $obj itself is undefed. Why? Because there's a B object that references it. And that B object won't go away because that A object references it too. So it's like the A and B are pointing at each other, keeping each other alive (this is called a circular reference.)

  Perl 5.6 added some magic called a 'weak reference'.

  package A;
  sub new { 
    my $class = shift;
    my $this = bless {}, $class;
    $this->{-twin} = new B(-twin => $this);
    return $this;
  }
  package B;
  sub new {
    my $class = shift;
    my $this = bless {@_}, $class;
    weaken $this->{-twin};
    return $this;
  }
  $obj = new A;
  undef $obj;
  [download]

  See the 'weaken'? That specific reference is now "weak", and does not actually add to the reference count (so the only reference to the A object is $obj). When $obj is then undefined, the reference count goes to zero, and any weak references are automatically set to undef by Perl. It's perfect for when you need backreferences that should not keep their referents alive.
• Builtin version of IO::Scalar

  $bar = "this\nthat\n";
  open(FH, '<', \$bar);
  $this = <FH>; # reads "this\n"
  $that = <FH>; # reads "that\n"
  open(FH, '>', \$bar);
  print FH "this\n";
  print FH "that\n";
  [download]

  This makes it very easy to convert a function that displays text to STDOUT into one returning its output as a string:

  # $foo = capture { print 'hi'; }
  # $foo will be filled as if someone had done $foo = `perl -e { print '
  +hi'; }` or something like that
  # if the sub prints directly to STDOUT, like:  print STDOUT 'hi'; then
  + the output will not be captured
  sub capture(&) {
      my ($oldsel, $fh, $ret);
      open($fh, '>', \$ret) or die "can't capture: $!";
      $oldsel = select($fh);
      &{$_[0]};
      select $oldsel;
      close($fh);
      $ret;
  }
  [download]

$"=$,,$_=q>|\p4<6 8p<M/_|<('=>
.q>.<4-KI<l|2$<6%s!<qn#F<>;$,
.=pack'N*',"@{[unpack'C*',$_]
}"for split/</;$_=$,,y[A-Z a-z]
         {}cd;print lc
[download]

Oh yes, I had forgotten about weak references. I personally don't have a use for them (yet), but I've seen a couple modules that use it which I couldn't install for that reason.

A built-in IO::Scalar is awesome! I use that pretty regularly, especially in unit tests. In fact, our co-branding code uses it extensively. Anything that makes it faster/easier/better to capture STDOUT will definitely be a win for us.

I have changed all my code to not use map in a void context because of the speed penalty and because it's "bad style". That said, I prefer not using it in this manner anyway. foreach() is much easier to read if you're just trying to loop through a list anyway. :-)

What matters to me most is, like you, that I can be confident in using new releases from the CPAN. Second comes use warnings; use diagnostics;.