Re: What with this open file descriptor/"Read on closed filehandle " stuff?

From: Rex Gustavus Adolphus (uffesterner_at_spamhole.com)
Date: 03/05/04 

Date: 5 Mar 2004 01:03:37 -0800

Hi Matt and Tassilo!

Even if we're now deviating from my original question I like to
comment some of your input.

"Matt Garrish" <matthew.garrish@sympatico.ca> wrote in message news:<IlP1c.8282$jw2.536723@news20.bellglobal.com>...
> "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de> wrote in message
> news:c2795a$t3o$1@nets3.rz.RWTH-Aachen.DE...
> > Also sprach Matt Garrish:
> >
> > > "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de> wrote in message
> > > news:c273gt$4o2$1@nets3.rz.RWTH-Aachen.DE...
> > >> Also sprach Rex Gustavus Adolphus:
> > >>
> > >> > Ben Morrow <usenet@morrow.me.uk> wrote in message
>
> > >> >> Don't call subs with & unless you need to (here you don't).
> > >> >
> > >> > Isn't this another case of TMTOWTDI?
> > >>
>
> >
> > Of the two side-effects that exist (passing @_ and circumventing the
> > prototype), only the latter could ever come into the game as the
> > parameters were passed explicitely. What remains are prototypes that
> > weren't used in this case.
> >
> > When speaking about prototypes, we have to acknowledge that they
> > themselves are a rather questionable concept. They were originally
> > introduced in order to create functions behaving similar to some
> > builtins (such as push() or map()). I don't see why the ampersand should
> > be condemned just because they affect something that is used in maybe 1%
> > of all function definitions in existing Perl code.
> >
>
> I don't disagree with you in principle, but you're still ackowledging that
> there are occasions where things may not happen as one expects when using an
> ampersand. The poster believed that it was just a style issue and Ben
> pointed out that this wasn't true, with the sound advice that one shouldn't
> use the & unless one needs to. You then countered to the effect that this
> was not true. Consequently, you leave the impression that it is just a style
> issue. It may only be < 1% of code that will ever be effected, but why not
> start someone off on a safer footing (i.e., have them discover the use of
> the ampersand when they need to pass the same @_ on, not by accident).
>
> I get the feeling that you're looking at the situation from the perspective
> of an experienced Perl programmer, in which case you don't need/want to be
> lectured on ampersands and their effects and just want to be left alone to
> use them (which is certainly your right). In the interests of promoting good
> programming techniques, however, I can't agree that the same hands-off
> approach should be taken with someone new to the language.

I get the same feeling, Matt, that you're looking at the situation
from the experienced Perl programmer perspective to.
I'm not very experienced in Perl, and so I never heard of the
different effects using/not using & in sub-calls.
A simple example would be great!

>
> >
> > Finally the statement
> >
> > Don't call subs with & unless you need to.
> >
> > is a violation against anything that Perl stands for.
>
> You're thinking of PERL. Perl stands for nothing... : )

What's PERL, Matt, ;) ?
quotes from perlfaq:
"Larry now uses "Perl" to signify the language proper and "perl" the
implementation of it, i.e. the current interpreter." +
"But never write "PERL", because perl is not an acronym, apocryphal
folklore and post-facto expansions notwithstanding."

RGA

Relevant Pages

  • Re: Dynamic Typing, Defencive Programming and Prototypes (Was: Interfaces and Type Safety)
    ... your example compiles but as soon as I try doing something after this sig ... > Note that tied hashes or arrays are conceptually overloading the subscript ... Another logical way to look at it is that it's unlikely that Perl ... syntactic sault for dealing with prototypes. ...
    (comp.lang.perl.misc)
  • Re: subroutine definitions
    ... > Perl prototypes strikes me as primarily a seed of confusion. ... When we have so many beginners tripping themselves up by trying to ...
    (perl.beginners)
  • Re: prototypes - use or not?
    ... DB> Perl Best Practices, section 9.10, has a pretty clear ... DB> statement that subroutine prototypes should not be ... (It says that the disadvantages generally outweigh ... just what pbp says, don't use them unless you have a very good reason to ...
    (comp.lang.perl.misc)
  • Re: What with this open file descriptor/"Read on closed filehandle " stuff?
    ... > has a special meaning in subroutine calls, ... When speaking about prototypes, we have to acknowledge that they ... I don't see why the ampersand should ... is a violation against anything that Perl stands for. ...
    (comp.lang.perl.misc)
  • Re: subroutine definitions
    ... > application of prototypes to allow inconsistent calling syntax does not seem to ... > me to add any clarity. ... but there-in lies the true power and true nightmare that is Perl. ...
    (perl.beginners)