Re: This Week on perl5-porters - 15-21 September 2008

["David Nicol" <davidnicol@gmail.com>]

On Sun, Sep 28, 2008 at 8:04 AM, David Landgren <david@landgren.net> wrote:
> This Week on perl5-porters - 15-21 September 2008
>

>  This reminded Jan Dubois of a subtlety he encountered with "unlink" a
>  while ago: "unlink()" will remove the file named by $_, but
>  "unlink(())" does nothing. The reason for this oddity is to prevent
>  "unlink(@stuff)" from unlinking whatever $_ points to, should @stuff
>  happen to be empty.
>
>  Jan gave up trying to implement the same semantics in pure Perl,
>  instead concluding that there are some core functions that are
>  impossible to duplicate. And perl 5.10's "_" prototype doesn't help
>  either, given that it imposes scalar context.

Which is something that seems bizarre, coming from a C++ background,
about perl prototypes:  they do not provide polymorphism!  So here's
the question:  Is implementing some mechanism, for 5.12, to allow
multiple subroutines to have the same name but different prototypes,
and the correct one gets brought in, useful enough to bless as a TO DO
item?

On the internal representation side,  to preserve late binding,
*foo{CODE} might get a arrayref in it instead of a coderef, or a
coderef to a redispatch routine, which would receive a representation
of the syntax of the call along with the name and the arguments.

On the declaration side of things, the full behavior of edge cases
like unlink and truncate could be modeled by writing more than one
routine.

   sub unlink(@){ carp "unlinking @_"; CORE::unlink(@_ }
   sub unlink(){ carp "unlinking $_"; CORE::unlink($_ }
   sub truncate($*){...}
   sub truncate($$){ ... }

---

Follow-Ups from:

Moritz Lenz <moritz@casella.verplant.org>
Aristotle Pagaltzis <pagaltzis@gmx.de>

References to:

David Landgren <david@landgren.net>

---

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

---