> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
NT> Casey R. Tweten writes:
>> Wow. Now that, that, is lame. You're saying that keys() expects
>> it's first argument to begin with a %? Why should it care what it's
>> argumen begins with?
NT> The keys function changes its arguments
I assure you that the number of people who get compile-time caught
for writing keys or each $x[$i][$j] or pop or push $x[$i][$j] is
*very* large. This is by far the most prevalent error that happens
with data structures in apprentice and perhaps even journeymen perl
programmers. Having the compi
In reply to your message from the not too distant future: next Tuesday AD
Reply-to: [EMAIL PROTECTED]
Return-receipt-to: [EMAIL PROTECTED]
Organization: a) Discordia b) none c) what's that?
Content-Typo: gibberish, charset=ascii-art
Date: Tue, 22 Aug 2000 13:48:36 EDT
From: Jerrad Pierce
>$n
In 42 lines, of which 25 were waste, Jerrad Pierce wrote:
>
> a) why this is the Wrong Thing
It is simply not the way perl works. In these matters at least, perl is
quite consistent.
> c) something to refute Do What I Mean
DWIM is cutesy, but not actually meaningful. Perl comes closer to dw
>Other than the issue of semantics (array is not list), I still have not
>seen:
>a) why this is the Wrong Thing
Why what is the wrong thing? Why treating an immutable list
as a mutable array is wrong? Because you can't change the length
of a list -- it doesn't have an AV to update. If you wan
In reply to your message from the not too distant future: next Tuesday AD
Reply-to: [EMAIL PROTECTED]
Organization: a) Discordia b) none c) what's that?
Content-Typo: gibberish, charset=ascii-art
Date: Tue, 22 Aug 2000 12:58:38 EDT
From: Jerrad Pierce
>I think you are still confused as to the di
Today around 10:11am, John Porter hammered out this masterpiece:
: Casey R. Tweten wrote:
: >
: > sub func {
: > return qw/KeyOne Value1 KeyTwo Value2/;
: > }
: >
: > print "$_\n" foreach keys &func();
:
: Please. There are ways -- well, just one way -- to do this, even in perl5.
:
:
>So the internals stay almost the same, but before resorting to die,
>you attempt a cast, if it works you warn that's inefficient under strict,
>and of course in the docs. If I occasionally want to be inefficient, I should
>have the license to do so. But I really don't think it'll be that less
>ef
In reply to your message from the not too distant future: next Monday AD
Reply-to: [EMAIL PROTECTED]
Return-receipt-to: [EMAIL PROTECTED]
Organization: a) Discordia b) none c) what's that?
Content-Typo: gibberish, charset=ascii-art
Date: Tue, 22 Aug 2000 10:15:48 EDT
From: Jerrad Pierce
>So, you
Casey R. Tweten wrote:
>
> sub func {
> return qw/KeyOne Value1 KeyTwo Value2/;
> }
>
> print "$_\n" foreach keys &func();
Please. There are ways -- well, just one way -- to do this, even in perl5.
print "$_\n" foreach keys %{{ func() }};
--
John Porter
We're building t
Today around 7:11pm, Tom Christiansen hammered out this masterpiece:
: >: No. keys() expects something that starts with a %, not
: >: something that starts with a &.
:
: >Wow. Now that, that, is lame. You're saying that keys() expects it's first
: >argument to begin with a %? Why should it c
On Mon, Aug 21, 2000 at 09:00:26PM -0400, Casey R. Tweten wrote:
> Today around 3:34pm, Tom Christiansen hammered out this masterpiece:
> : No. keys() expects something that starts with a %, not
> : something that starts with a &.
>
> Wow. Now that, that, is lame. You're saying that keys() exp
Casey R. Tweten writes:
> Wow. Now that, that, is lame. You're saying that keys() expects
> it's first argument to begin with a %? Why should it care what it's
> argumen begins with?
The keys function changes its arguments' data structure. keys resets
the each iterator (see the documentation
>: No. keys() expects something that starts with a %, not
>: something that starts with a &.
>Wow. Now that, that, is lame. You're saying that keys() expects it's first
>argument to begin with a %? Why should it care what it's argumen begins with?
You're just now figuring this out? Really?
Today around 3:34pm, Tom Christiansen hammered out this masterpiece:
: >Today around 11:48am, Tom Christiansen hammered out this masterpiece:
:
: >: >So basically, it would be nice if each, keys, values, etc. could all deal
: >: >with being handed a hash from a code block or subroutine...
: >:
>Today around 11:48am, Tom Christiansen hammered out this masterpiece:
>: >So basically, it would be nice if each, keys, values, etc. could all deal
>: >with being handed a hash from a code block or subroutine...
>:
>: In the current Perl World, a function can only return as output to
>: its cal
Today around 11:48am, Tom Christiansen hammered out this masterpiece:
: >So basically, it would be nice if each, keys, values, etc. could all deal
: >with being handed a hash from a code block or subroutine...
:
: In the current Perl World, a function can only return as output to
: its caller a
>So basically, it would be nice if each, keys, values, etc. could all deal
>with being handed a hash from a code block or subroutine...
In the current Perl World, a function can only return as output to
its caller a LIST, not a HASH nor an ARRAY. Likewise, it can only
receive a LIST, not those o
Why is it that in perl 5 I can do:
use English::Dereference; #Or equivalent, relevant section included below
sub ARRAY {
return @{ shift() };
}
sub HASH {
return %{ shift() };
}
print join(' ', ARRAY [1,2,3,4]), "\n";
And the seemingly parallel:
print join(' ', HASH {1,2,3,4}), "\n";
19 matches
Mail list logo
