$NF for perl

Discussion in 'Perl Misc' started by Tabe Kooistra, Jun 5, 2004.

  1. perldoc split reads:

    "In scalar context, returns the number of fields found and
    splits into the @_ array. Use of split in scalar context
    is deprecated, however, because it clobbers your subroutine
    arguments."

    perl v5.8.2

    somebody has a pointer or a hint to achieve this?

    regards,
    Tabe
    Tabe Kooistra, Jun 5, 2004
    #1
    1. Advertising

  2. In article <>,
    Tabe Kooistra <> wrote:
    :perldoc split reads:

    :"In scalar context, returns the number of fields found and
    :splits into the @_ array.

    :somebody has a pointer or a hint to achieve this?

    You have not indicated what it is you want to achieve.

    If what you want to get out is *just* the number of fields, then
    just ensure that you are in a list conext at the point the split
    is evaluated, and then scalar() that context.

    A couple of months ago, I saw someone here use an idiom about that.
    It was something *like*

    my $number_of_fields = scalar( () = split ... )

    The assignment to () provided the list context.
    --
    Contents: 100% recycled post-consumer statements.
    Walter Roberson, Jun 5, 2004
    #2
    1. Advertising

  3. Tabe Kooistra wrote:
    > perldoc split reads:
    >
    > "In scalar context, returns the number of fields found and
    > splits into the @_ array. Use of split in scalar context
    > is deprecated, however, because it clobbers your subroutine
    > arguments."
    >
    > perl v5.8.2
    >
    > somebody has a pointer or a hint to achieve this?


    What is "this"? You didn't tell us what you want to achive.

    jue
    Jürgen Exner, Jun 5, 2004
    #3
  4. Tabe Kooistra

    Brad Baxter Guest

    On Sat, 5 Jun 2004, Walter Roberson wrote:
    >
    > If what you want to get out is *just* the number of fields, then
    > just ensure that you are in a list conext at the point the split
    > is evaluated, and then scalar() that context.
    >
    > A couple of months ago, I saw someone here use an idiom about that.
    > It was something *like*
    >
    > my $number_of_fields = scalar( () = split ... )
    >
    > The assignment to () provided the list context.


    And the assignment to $n... provides the scalar context, so scalar() isn't
    needed. There are good reasons not to use scalar() when it isn't needed.

    my $number_of_fields = () = split ...

    Regards,

    Brad
    Brad Baxter, Jun 5, 2004
    #4
  5. Tabe Kooistra

    dirtWater Guest

    Tabe Kooistra <> wrote in message news:<>...
    > perldoc split reads:
    >
    > "In scalar context, returns the number of fields found and
    > splits into the @_ array. Use of split in scalar context
    > is deprecated, however, because it clobbers your subroutine
    > arguments."
    >
    > perl v5.8.2
    >
    > somebody has a pointer or a hint to achieve this?
    >
    > regards,
    > Tabe


    Is this the type of thing you are after?

    !/usr/bin/perl

    &mySub('x','x');
    &mySub('x','x','x','x');

    sub mySub{
    $x=$#_;
    $y=@_;
    print "$x is my last Index and I have $y elements\n";
    my(@args)=@_;
    print join "\n",@args;
    print "\n----\n";
    }
    [root@localhost root]# perl numSplit
    1 is my last Index and I have 2 elements
    x
    x
    ----
    3 is my last Index and I have 4 elements
    x
    x
    x
    x
    ----
    dirtWater, Jun 6, 2004
    #5
  6. On Sat, 05 Jun 2004 18:56:35 -0400, Brad Baxter wrote:

    > On Sat, 5 Jun 2004, Walter Roberson wrote:
    >>
    >> my $number_of_fields = scalar( () = split ... )
    >>
    >> The assignment to () provided the list context.

    >
    > And the assignment to $n... provides the scalar context, so scalar() isn't
    > needed. There are good reasons not to use scalar() when it isn't needed.
    >
    > my $number_of_fields = () = split ...
    >


    thank you!
    Tabe
    Tabe Kooistra, Jun 6, 2004
    #6
  7. In article <>,
    Brad Baxter <> wrote:

    > And the assignment to $n... provides the scalar context, so scalar() isn't
    > needed. There are good reasons not to use scalar() when it isn't needed.


    What would such reasons be? I often use it for clarity's sake even when
    it isn't strictly necessary -- what side effects does it have that might
    be invidious? `perldoc -f scalar` and `perldoc -q scalar` don't seem to
    note any deleterious side effects...

    Ricky
    Richard Morse, Jun 18, 2004
    #7
  8. Tabe Kooistra

    Anno Siegel Guest

    Richard Morse <> wrote in comp.lang.perl.misc:
    > In article <>,
    > Brad Baxter <> wrote:
    >
    > > And the assignment to $n... provides the scalar context, so scalar() isn't
    > > needed. There are good reasons not to use scalar() when it isn't needed.

    >
    > What would such reasons be? I often use it for clarity's sake even when
    > it isn't strictly necessary -- what side effects does it have that might
    > be invidious? `perldoc -f scalar` and `perldoc -q scalar` don't seem to
    > note any deleterious side effects...


    I am strongly opposed to adding stuff to code "for clarity's sake", even
    if it provably doesn't hurt.

    For one, it doesn't accomplish its purpose. The process of understanding
    code is largely understanding why every bit is where it is. If some bits
    are there just because the author liked it that way, that makes this
    process harder, not easier. That goes for scalar() when context is already
    scalar as well as for unnecessary quoting of variables, unnecessary escaping
    in strings and regexes, unnecessary variable initializations and a host
    of less frequent unnecessarities.

    Unnecessary code also tends to diminish the reader's trust in the author.
    Your intention may have been clarity, but for all the reader knows you
    have been hedging your bets because you weren't sure if a construct was
    needed or not. Bad move. You want the reader to believe you know what
    you're doing. Doing things you might as well not do is unconvincing in
    that respect. Of course, it helps if you, in actual fact, know what
    you're doing.

    If a bit of code needs additional clarification, add a comment (or, better,
    re-write it so that it doesn't). Using redundant code for the purpose
    sends out mixed signals.

    On a more general note, adding things for clarity means you are trying
    to guess what constructs in your code will be difficult for the reader
    to understand. That is incredibly hard to do. Programmers have wildly
    different educational histories, and what you find hard (or once found
    hard) may well be a matter of course for someone else, and vice versa.
    Expect your readers to stumble over things you take for granted and apply
    casually, not even thinking of clarification.

    Anno
    Anno Siegel, Jun 18, 2004
    #8
  9. In article <cav2b6$m3n$-Berlin.DE>,
    Anno Siegel <-berlin.de> wrote:
    :I am strongly opposed to adding stuff to code "for clarity's sake", even
    :if it provably doesn't hurt.

    I disagree. But then I learned through the school of defensive
    programming.

    For example, initialize variables even if the algorithm will certainly
    set the variable value -- because there might be a bug in the
    algorithm, or you might end up being interrupted out of the code, or
    some variable might assume an unexpected value due to real-time
    interactions ('volatile' in C), or some variable might get clobbered
    through an alias or stray or uninitialized pointer. Or because someone else
    might come along later and add some code that allows the basic block
    to be exitted without the variable having been set according to the
    algorithm.

    Don't assume your code will be right: assume your code will be wrong
    (or will *become* wrong over time... possibly because of changes to the
    language spec), and protect yourself against the possibilities.

    It's a lot harder to show "proof of correctness" when some variables
    might have undefined or indeterminate values, so it's better to
    overcode than to rely upon the boundary conditions of the current version
    of the language.
    --
    Warhol's Second Law of Usenet: "In the future, everyone will troll
    for 15 minutes."
    Walter Roberson, Jun 18, 2004
    #9
  10. Tabe Kooistra

    Anno Siegel Guest

    Walter Roberson <-cnrc.gc.ca> wrote in comp.lang.perl.misc:
    > In article <cav2b6$m3n$-Berlin.DE>,
    > Anno Siegel <-berlin.de> wrote:
    > :I am strongly opposed to adding stuff to code "for clarity's sake", even
    > :if it provably doesn't hurt.
    >
    > I disagree. But then I learned through the school of defensive
    > programming.
    >
    > For example, initialize variables even if the algorithm will certainly
    > set the variable value -- because there might be a bug in the
    > algorithm, or you might end up being interrupted out of the code, or
    > some variable might assume an unexpected value due to real-time
    > interactions ('volatile' in C), or some variable might get clobbered
    > through an alias or stray or uninitialized pointer. Or because someone else
    > might come along later and add some code that allows the basic block
    > to be exitted without the variable having been set according to the
    > algorithm.


    Let me first point out that I was talking about Perl and Perl variables,
    not languages and variables in general. Your arguments above may pertain
    to C, but not to Perl. Here, the "uninitialized value" is a clearly
    recognizable state of a variable. The question is usually only if
    the surrounding code can cope with an undef or not, often a design
    decision.

    So, in Perl, it makes sense to initialize variables only if undef
    isn't good enough. That tends to be rather rare, so it tells the
    reader something -- a good thing.

    Note also, that I'm not advocating sloppy programming. When I say,
    avoid redundant code, I mean code that can go without making a
    difference. In Perl, variable initialization happens to be such
    code more often than in other languages.

    > Don't assume your code will be right: assume your code will be wrong
    > (or will *become* wrong over time... possibly because of changes to the
    > language spec), and protect yourself against the possibilities.


    No disagreement here.

    > It's a lot harder to show "proof of correctness" when some variables
    > might have undefined or indeterminate values, so it's better to
    > overcode than to rely upon the boundary conditions of the current version
    > of the language.


    Again, in Perl, undef is a perfectly respectable value with predictable
    behavior, unlike a random value that is indistinguishable from a legitimate
    one. If code and environment go out of sync wrt. undef, you usually see
    warnings that weren't there before. Thus, defensive initialization can
    mask bugs that would be obvious without it.

    Anno
    Anno Siegel, Jun 18, 2004
    #10
  11. In article <cav2b6$m3n$-Berlin.DE>,
    -berlin.de (Anno Siegel) wrote:

    > Richard Morse <> wrote in comp.lang.perl.misc:
    > > In article <>,
    > > Brad Baxter <> wrote:
    > >
    > > > And the assignment to $n... provides the scalar context, so scalar() isn't
    > > > needed. There are good reasons not to use scalar() when it isn't needed.

    > >
    > > What would such reasons be? I often use it for clarity's sake even when
    > > it isn't strictly necessary -- what side effects does it have that might
    > > be invidious? `perldoc -f scalar` and `perldoc -q scalar` don't seem to
    > > note any deleterious side effects...

    >
    > I am strongly opposed to adding stuff to code "for clarity's sake", even
    > if it provably doesn't hurt.
    >
    > For one, it doesn't accomplish its purpose. The process of understanding
    > code is largely understanding why every bit is where it is. If some bits
    > are there just because the author liked it that way, that makes this
    > process harder, not easier. That goes for scalar() when context is already
    > scalar as well as for unnecessary quoting of variables, unnecessary escaping
    > in strings and regexes, unnecessary variable initializations and a host
    > of less frequent unnecessarities.


    As an example, I prefer the following:

    my $var = scalar(@array);

    instead of:

    my $var = @array;

    because it explicates that I'm interested in the size of the array --
    and makes it obvious that I didn't mistype the sigil in front of 'var'.

    I also, on the few occasions when I use c-style loops, prefer:

    for (my $i = 0; $i < scalar(@array); $i++) {
    }

    although the reason for this doesn't spring to mind -- probably because
    it's how I taught myself (I only discovered this forum a few months
    back, although I have been programming in Perl for about five years now).

    I don't really see that either of these two cases makes it harder to
    understand the code -- in fact, when I'm reading over it really quickly,
    it makes it easier...

    Ricky
    Richard Morse, Jun 18, 2004
    #11
  12. Tabe Kooistra

    Anno Siegel Guest

    Richard Morse <> wrote in comp.lang.perl.misc:
    > In article <cav2b6$m3n$-Berlin.DE>,
    > -berlin.de (Anno Siegel) wrote:


    > > I am strongly opposed to adding stuff to code "for clarity's sake", even
    > > if it provably doesn't hurt.


    [...]

    > As an example, I prefer the following:
    >
    > my $var = scalar(@array);
    >
    > instead of:
    >
    > my $var = @array;
    >
    > because it explicates that I'm interested in the size of the array --
    > and makes it obvious that I didn't mistype the sigil in front of 'var'.


    That's an error that would almost certainly be detected elsewhere under
    strict. No need for special guards against that.

    > I also, on the few occasions when I use c-style loops, prefer:
    >
    > for (my $i = 0; $i < scalar(@array); $i++) {
    > }
    >
    > although the reason for this doesn't spring to mind -- probably because
    > it's how I taught myself (I only discovered this forum a few months
    > back, although I have been programming in Perl for about five years now).


    It's just another case of accessing the array size. If you do one, you
    practically have to do the other.

    > I don't really see that either of these two cases makes it harder to
    > understand the code -- in fact, when I'm reading over it really quickly,
    > it makes it easier...


    A matter of habit, I suppose. I do have to look twice and condition my
    perception to ignore the "scalar".

    It also depends on the frame of reference. Since I know you as a
    trustworthy Perl programmer, I know how to read it. Seen in isolation,
    it would make me wonder if you had understood the concept of scalar
    context. In beginner's code, posted to clpm, say, I would certainly
    point out that "scalar" is redundant for this reason. A construct that
    is bad in beginner's code should be avoided in advanced code unless
    there is a strong reason to use it. Is the "context clarification"
    it provides a strong-enough reason? Your call.

    Context dependency is one of the very distinctive features of Perl.
    No other language, except natural languages, makes use of it to quite
    that extent, and it's the one feature that contributes most to making
    Perl a bit like natural languages. So here's the killer argument
    against scalar() in scalar context:

    It is un-natural and unperlish!

    So there.

    Anno
    Anno Siegel, Jun 19, 2004
    #12
  13. Tabe Kooistra

    Brad Baxter Guest

    On Fri, 18 Jun 2004, Richard Morse wrote:

    > In article <>,
    > Brad Baxter <> wrote:
    >
    > > And the assignment to $n... provides the scalar context, so scalar() isn't
    > > needed. There are good reasons not to use scalar() when it isn't needed.

    >
    > What would such reasons be? I often use it for clarity's sake even when
    > it isn't strictly necessary -- what side effects does it have that might
    > be invidious? `perldoc -f scalar` and `perldoc -q scalar` don't seem to
    > note any deleterious side effects...


    Others have given their points of view, with which I essentially agree.
    I'll add that for myself, if I see scalar (for example) used when it isn't
    needed, I wonder if perhaps there's a typo in that line, i.e., did the
    programmer mean to have something different there and didn't notice? So
    rather than clarifying the usage, it creates a mental speed bump. Of
    course, you could put a comment that explains 'scalar' is there for
    clarity, but that would be a bit over the top. :)

    Regards,

    Brad
    Brad Baxter, Jun 23, 2004
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. dpackwood
    Replies:
    3
    Views:
    1,767
  2. PerlFAQ Server

    FAQ 1.4 What are Perl 4, Perl 5, or Perl 6?

    PerlFAQ Server, Jan 23, 2011, in forum: Perl Misc
    Replies:
    0
    Views:
    286
    PerlFAQ Server
    Jan 23, 2011
  3. PerlFAQ Server
    Replies:
    0
    Views:
    652
    PerlFAQ Server
    Feb 3, 2011
  4. PerlFAQ Server

    FAQ 1.4 What are Perl 4, Perl 5, or Perl 6?

    PerlFAQ Server, Feb 27, 2011, in forum: Perl Misc
    Replies:
    0
    Views:
    276
    PerlFAQ Server
    Feb 27, 2011
  5. PerlFAQ Server
    Replies:
    0
    Views:
    661
    PerlFAQ Server
    Apr 4, 2011
Loading...

Share This Page