develooper Front page | perl.perl5.summary | Postings from November 2002

This Week on perl5-porters (18-24 November 2002)

Rafael Garcia-Suarez
November 26, 2002 00:06
This Week on perl5-porters (18-24 November 2002)
Message ID:
This Week on perl5-porters (18-24 November 2002)
  Several longs threads will be summarized for your enjoyment and
  education in this week's P5P summary. Learn about how new features are
  added in perl! How to enhance a core module like Carp! How to change the
  implementation of a command-line switch! How to change the semantics of
  require()! How to introduce a new warning! And, last but not least, how
  to modify the perl parser itself! Ain't it exciting ?

Carp patch, rejected
  Brent Dax proposed a patch to the Carp module, to allow

      use Carp 'die';
      use Carp 'warn';

  to install references to cluck() and confess() in the $SIG{__DIE__} and
  $SIG{__WARN__} handlers, respectively.

  Michael G Schwern commented that overriding warn() and die() in the
  package that uses Carp may be more useful, since signal handlers are

  Hugo van der Sanden made a similar remark : changing $SIG{__DIE|WARN__}
  this way feels like pragmatic behaviour, expected to be reversible by a
  simple "no Carp '...'". Hence he rejected the proposed patch to avoid

require $foo versus require Foo
  Matt Sergeant asked why the behavior of "require" is different when it's
  followed by a string or by a bareword, as in :

      require IO::Socket;
      require 'IO/';

  Tim Bunce explained that the bareword argument is intended to provide a
  package name, while the string argument is intended to provide a file
  name. Jan Dubois helpfully added that this enables to distinguish
  between the two forms

      require 'Foo'; # loads a file Foo
      require Foo;   # loads a file

  Michael G Schwern then pointed out his UNIVERSAL::require module, that
  provides an equivalent syntax "Foo->require()".

  Jos Boumans then proposed to provide a new function, via a carefully
  named module, to load modules and files at runtime with an appropriate
  amount of DWIMmery.

Atomic in-place edit
  Eduardo PĂ©rez Ureta remarked that the "-i" command-line switch, used in
  one-liners to edit files in place, first performs an unlink of the
  original file (after having opened it for reading), then reads it while
  it writes to a new file, just opened for writing under the same name.
  Potentially, this can cause some data to be lost, when some failure

  It was pointed out that doing the rename by hand, or using a backup file
  (as with "-i.bak") makes the operation more reliable ; however that
  doesn't necessarily mean that "-i" by itself shouldn't be made more
  reliable if it's reasonably possible. Eduardo proposed that a temporary
  file should be used for output instead. This change also would make
  possible to use "-i" without a backup extension on Windows systems,
  where it's not possible to unlink an opened file.

  During the discussion, I recalled a little-known feature of "-i",
  described in perlrun : its ability to create backup files in any
  directory, with the syntax "-i/tmp/*.bak".

  In any case, true atomicity for every possible failure mode can't be
  achieved. Mark Jason Dominus submitted a bug report for the universe.

Called as a subroutine or as a method ?
  Yves Orton asked for *a way to determine if a sub was called as a
  subroutine or as a method*.

  Apparently there is no way to get this information from perl : digging
  into the internals is necessary. Richard Clamp provided an update to his
  Devel::Caller module that adds a called_as_method() function, to answer
  this exact question.

Parser patch for "? :"
  Stephen McCamant provided a one-line patch to the perl parser that
  modifies the way the "? :" ternary operator binds its second argument.

  In other words : currently the following are syntax errors :

      $a = $b ? $c, $d : $e;
      $a = $b ? $c and $d : $e;

  because the precedence of the comma-operator and of textual logical
  operators are very low. However it's possible to parse them
  unambiguously, and that's what Stephen's patch does, without introducing
  any backward incompatibility (if I'm not mistaken).

New warning proposal
  Rafael Garcia-Suarez proposed a new compile-time warning for Perl, to
  detect potential misleading uses of split(), namely when the first
  argument is written as a string (but interpreted, as always, as a
  pattern.) The canonical example is

      my @array = split '|', $string;

  that doesn't probably do what was meant.

  It appears that running regression tests with this new warning reveals
  that eleven core modules use this syntax (sometimes unreasonably, as in
  "split '\.', $string"). Brent Dax suggested that the warning should be
  triggered only on strings with metacharacters, the other cases not
  leading to confusion. Hugo liked this last idea, though being *still
  dubious that the benefits outweigh the irritation.*

In brief
  Ronald Otto Valentin Fischer reported bug #18479, about "use strict
  'subs'" not detecting barewords in an eval("")'d BEGIN block.

  H.Merijn Brand reported that the test t/io/openpid.t began to hang on
  AIX 4.3.3. No workaround is known, so no smoke reports have been
  produced for this system.

  Bugs #18489, #18579 and #18571 are about small snippets of code that
  make perl dump core. (In fact, the first two are equivalent bugs.) They
  all involve modifying an array while a foreach loop iterates over it (or
  kind of). Dave Mitchell commented : *in the longer term, Perl should be
  fixed so that it doesn't coredump in such situations (but this is hard
  to do efficiently)*.

  Bug #18573 demonstrates a strange memory allocation problem : "eval
  q("\c")" produces an "Out of memory" error.

  Joost van Baal and Slaven Rezic tried to work out a solution to a
  Sys::Syslog portability problem on Solaris (bug #18180).

  Dave Mitchell proposed a new version of his patch to allow eval("") to
  see the full enclosing lexical scope. This patch follows a discussion
  about lexicals in evals that occured two weeks ago.

  Rafael Garcia-Suarez fixed bug #17920, a case of parser coredump, and
  added a new test file t/comp/parser.t aimed at testing that syntax
  errors are correctly reported. He moved also some tests there from the
  infamous t/run/fresh_perl.t (aimed at testing things that used to dump
  core, a sloppy classification for tests indeed.)

About this summary
  This summary brought to you by Rafael Garcia-Suarez, both on and via a mailing list, which subscription address
  is Comments and corrections are, as
  always, welcome. Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About