This Week on perl5-porters (29 March - 5 April 2004)

With a little delay comes this week the weekly Perl 5 Porters Summary from the
centre of reality that is Echt, the Netherlands.  About 250 messages were
posted in the last week.  A lot was said about documentation.  And a Release
Candidate was released!  Well, technically not inside the week, but inside of
the bounds of this summary, anyway.

No stacked filetest operators

  Oops.  I misinterpreted 5.8.4's changelog.  Perl 5.8.4 will not have stacked
  filetest operators.  Thanks to Paul Johnson for pointing this out.

  http://groups.google.com/groups?selm=20040329000412.GL23954%40pjcj.net

Indirect notation in core documentation

  Yves Orton started a discussion about the usage of indirect object notation
  in Perl's core documentation, and whether the Perl core documentation should
  give the good example by not using indirect object notation.  Beginning Perl
  programmers would be confused by this extra synctactic sugar (well, I know
  when I was starting doing Perl objects).

  http://groups.google.com/groups?th=65e7cde0bc3e30b5

The ref( $proto ) || $proto Debate

  Ovid started a discussion aka can of worms about the use of the archetypical
  idiom

  sub new {
   my $proto = shift;
   my $class = ref( $proto ) || $proto;

  in Perl's core documentation as it introduces cargo-culting (even though it
  is documented in perltoot).  The discussion continued on what it actually
  means when you call "new" on an object as opposed to on a class (bareword).
  Randal Schwartz ended the discussion with a preview of one of his upcoming
  articles, in which he basically said that there would always be 67% of the
  people expecting the wrong thing from calling "new" on an object.  A patch
  was supplied by Ovid in the end: it was applied.

  http://groups.google.com/groups?th=fe974d9bbcd41d9e
  http://groups.google.com/groups?th=f6a921f8df9d8529

wantarray inside eval block

  Tim Bunce reported that wantarray seems to behave differently inside an eval
  block from e.g. a do block.  Rafael added a documentation patchlet.
  Personally, I'm not sure whether this is actually a bug or a feature: in any
  case, it's documented now.

  http://groups.google.com/groups?th=8e7e5816a64a07

localtime() not mentioning gmtime() and vice versa

  Dan Jacobson reported that the perl documentation of localtime() doesn't
  mention gmtime() and vice versa.  He didn't supply a proposal for a change
  in the documentation, or a patch.  Too bad.  It would have improved Perl's
  documentation with little effort on his side.  Nobody has reacted so far.

  http://groups.google.com/groups?th=592e945ce45de89d

The version saga continues

  As promised last week, John Peacock uploaded a new version of version.pm on
  CPAN.  This version included some extra's not in the core, which immediately
  exposed yet another problem of modules living both in the core as well as on
  CPAN: if version X of something on CPAN includes more files than version X in
  the core, how will CPAN.pm or CPANPLUS.pm ever download the CPAN version?

  http://groups.google.com/groups?th=10d2d4819de85a28

Signed big and little endian in (un)pack

  Marcus Holland-Moritz had a feature request for allowing pack to directly
  support signed little and big endian integers in (un)pack.  His original
  proposal used extra letters.  Merijn H. Brand thought the proposal was
  a good idea, but that it was using too much letter real estate.  A different
  proposal and patch using a "!" suffix was given later, but as yet not
  committed.

  http://groups.google.com/groups?th=a9d9e46d9942125f
  http://groups.google.com/groups?th=d94d1939b525d878

Nick keeps the pressure on!

  Perl 5.8.4 RC1 was released by Nicholas Clark.  Expect a proper 5.8.4 in a
  week or so!

  http://groups.google.com/groups?th=8d87fae1ec5e402b

About this summary

  This summary was written by Elizabeth Mattijsen, from Echt, The Netherlands
  while Rafael is still getting settled in Paris. Weekly summaries are published
  on http://use.perl.org/ and posted on a mailing list, which subscription
  address is [email protected].  Comments and corrections are
  welcome.