«

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

In article <> ,
Tabe Kooistra <> wrote:
erldoc 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.

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

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

Tabe Kooistra <> wrote in message news:< et>...
> 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
----

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

In article <. edu>,
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 <> wrote in comp.lang.perl.misc:
> In article <. edu>,
> 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

In article <cav2b6$m3n$>,
Anno Siegel <> 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 <> wrote in comp.lang.perl.misc:
> In article <cav2b6$m3n$>,
> Anno Siegel <> 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