$NF for perl

[Tabe Kooistra]

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

 

[Walter Roberson]

:"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.

 

[Jürgen Exner]

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

 

[Brad Baxter]

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

 

[dirtWater]

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
----

 

[Tabe Kooistra]

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

 

[Richard Morse]

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

 

[Anno Siegel]

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

 

[Walter Roberson]

: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.

 

[Anno Siegel]

: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

 

[Richard Morse]

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

 

[Anno Siegel]

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

 

[Brad Baxter]

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