«

I've been reading Beginning Per & Programming Perl from O'Reilly for some time
now and I'm getting used to references and how to grow them..

But why would someone use a reference if they can use a normal variable? Yeah, I
know, with references you can grow complex data structures, but in simple
programs, why would you use them (=references)?

Thanks for your (smart) answers

Greets from Belgium,

Thomas

In article <c08d6u$89k$>,
Thomas Deschepper <> wrote:
:I've been reading Beginning Per & Programming Perl from O'Reilly for some time
:now and I'm getting used to references and how to grow them..

:But why would someone use a reference if they can use a normal variable? Yeah, I
:know, with references you can grow complex data structures, but in simple
rograms, why would you use them (=references)?

I've used languages where every subroutine argument was call- by-
reference, and I've used languages where every subroutine argument
was call- by- value, and I've used languages where every subroutine
argument had to be explicitly declared as by-reference or by-value.

perl, though, implicitly passes a reference if possible, and
otherwise passes by value. In my opinion, that leads to too much
chance of making a mistake (and hence to unpredicted behaviour),
so I prefer to not count on call-by-reference behaviour and instead
explicitly pass through a reference if I'm expecting to change the
argument.
--
I've been working on a kernel
All the livelong night.
I've been working on a kernel
And it still won't work quite right. -- J. Benson & J. Doll

(Walter Roberson) wrote:
> perl, though, implicitly passes a reference if possible, and
> otherwise passes by value.

Eh what? Perl always passes aliases into @_, and the standard idiom
of

my ($a, $b) = @_;

then makes copies. What's implicit about that?

Ben

--
Musica Dei donum optimi, trahit homines, trahit deos. |
Musica truces molit animos, tristesque mentes erigit. |
Musica vel ipsas arbores et horridas movet feras. |

Thomas Deschepper <> wrote:
> I've been reading Beginning Per & Programming Perl from O'Reilly for some
> time now and I'm getting used to references and how to grow them..
>
> But why would someone use a reference if they can use a normal variable?

I wouldn't use a reference if I could just as well use a normal variable,
unless I anticipate the program will eventually evolve such that I
couldn't use a normal variable there anymore. In that case I would
preemptively use a reference.

> Yeah, I know, with references you can grow complex data structures, but
> in simple programs, why would you use them (=references)?

I wouldn't. I'm not sure I understand your question. Do you often see
people gratuitiously using references?

use strict;
my $x;
my $y;
$$$$y=0;
while ($$$$x=<>) {
$$$$y+=$$$$x;
};
print $$$$y;


> Thanks for your (smart) answers
^
ass


Cheers,


Xho

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service New Rate! $9.95/Month 50GB

In article <c08eug$ml5$>,
Ben Morrow <> wrote:

: (Walter Roberson) wrote:
:> perl, though, implicitly passes a reference if possible, and
:> otherwise passes by value.

:Eh what? Perl always passes aliases into @_, and the standard idiom
f

:my ($a, $b) = @_;

:then makes copies. What's implicit about that?

It is implicit compared to (say) Pascal's "VAR" notation, or even
compared to C's (type *) notation. The closest, I guess, would
be FORTRAN's behaviour.


I've had a number of practically untracable bugs, with values
used in one subroutine suddenly reappearing in the next subroutine
down -- even though the calling routine has the right value for
the parameter. I eventually decided it was happening mostly in places
I was using the (shift) idiom, and re-wrote all of those.
[I -think- I also had it happen a few times where I used my $var = $_[0]
but I'm not positive about that.] Looking back over the documentation
of shift, it seems to me that it must be the case that shift preserves
the property of being an alias, and that for my $var = shift
that $var ends up an alias to the parameter passed down. That's
certainly not explicit behaviour.
--
"Mathematics? I speak it like a native." -- Spike Milligan

Thomas Deschepper () wrote:
: I've been reading Beginning Per & Programming Perl from O'Reilly for some time
: now and I'm getting used to references and how to grow them..

: But why would someone use a reference if they can use a normal variable? Yeah, I
: know, with references you can grow complex data structures, but in simple
: programs, why would you use them (=references)?

Style. (?)

I suspect that someone who uses a lot of references feels comfortable
with the syntax and may use them even when they are not needed.

I prefer
$my_hash{$item}

but someone else might prefer

$my_hash->{$item}

It makes no difference to the interpreter, so use which ever style you
prefer (they are different of course, it just doesn't _make_ any
difference).

If the program has other references (that are needed) that using
references everywhere might also make the program more consistent,
stylisticly.

$myhash1->{$item}
$myhash2->{$item}
$myhash3{$item} # huh, why is this different?

(Walter Roberson) wrote:
> In article <c08eug$ml5$>,
> Ben Morrow <> wrote:
>
> : (Walter Roberson) wrote:
> :> perl, though, implicitly passes a reference if possible, and
> :> otherwise passes by value.
>
> :Eh what? Perl always passes aliases into @_, and the standard idiom
> f
>
> :my ($a, $b) = @_;
>
> :then makes copies. What's implicit about that?
>
> It is implicit compared to (say) Pascal's "VAR" notation, or even
> compared to C's (type *) notation. The closest, I guess, would
> be FORTRAN's behaviour.
>
> I've had a number of practically untracable bugs, with values
> used in one subroutine suddenly reappearing in the next subroutine
> down -- even though the calling routine has the right value for
> the parameter. I eventually decided it was happening mostly in places
> I was using the (shift) idiom, and re-wrote all of those.
> [I -think- I also had it happen a few times where I used my $var = $_[0]
> but I'm not positive about that.] Looking back over the documentation
> of shift, it seems to me that it must be the case that shift preserves
> the property of being an alias, and that for my $var = shift
> that $var ends up an alias to the parameter passed down. That's
> certainly not explicit behaviour.

No, you've got something wrong somewhere, or you're calling subs with
&.

perl -le'sub a { my $x = shift; $x++ } my $y = 1; a $y; print $y'
1

perl -le'sub a { my $x = $_[0]; $x++ } my $y = 1; a $y; print $y'
1

perl -le'sub a { $_[0]++ } my $y = 1; a $y; print $y'
2

You only get aliasing if you explicitly manipulate $_[n]. Even so, I
agree it's rarely useful now we have prototypes. Perl6 will make @_
contain *readonly* aliases by default, so $_[0]++ will give a run-time
error.

Ben

--
"If a book is worth reading when you are six, *
it is worth reading when you are sixty." - C.S.Lewis

On Mon, 9 Feb 2004, Walter Roberson wrote:
> Looking back over the documentation of shift, it seems to me that it
> must be the case that shift preserves the property of being an alias,
> and that for my $var = shift that $var ends up an alias to the parameter
> passed down. That's certainly not explicit behaviour.

That's also not what it does. It says the opposite in the first line
of the documentation:

shift ARRAY
shift
Shifts the first value of the array off and returns it, ...

This is fairly easy to verify:

sub by_ref { \$_[0] }
sub by_assign1 { my( $x ) = @_; \$x; }
sub by_assign2 { my $x = $_[0]; \$x; }
sub by_shift { my $x = shift; \$x; }

my $y = 'test';

print "itself: ",\$y,"\n\n";

print "by_ref: @{[by_ref ( $y )]}\n";
print "by_assign1: @{[by_assign1( $y )]}\n";
print "by_assign2: @{[by_assign2( $y )]}\n";
print "by_shift: @{[by_shift ( $y )]}\n";

__END__
itself: SCALAR(0x106480)

by_ref: SCALAR(0x106480)
by_assign1: SCALAR(0x106540)
by_assign2: SCALAR(0x126f5c)
by_shift: SCALAR(0x126e90)

So you can see that with shift, the variable doesn't end up as an alias
any more than with any of the other assignments. They all copy values--and
pretty explicitly, it seems to me.

Regards,

Brad

"Malcolm Dew-Jones" <> wrote in message
news:...

> I prefer
> $my_hash{$item}
>
> but someone else might prefer
>
> $my_hash->{$item}

errr .. those two are not the same.

> It makes no difference to the interpreter, so use which ever style you
> prefer (they are different of course, it just doesn't _make_ any
> difference).

I don't understand how two different things don't make any difference (not
sure if the sentence itself makes sense, though).

> If the program has other references (that are needed) that using
> references everywhere might also make the program more consistent,
> stylisticly.

Agreed.

> $myhash1->{$item}
> $myhash2->{$item}
> $myhash3{$item} # huh, why is this different?

Maybe because $myhash1 and $myhash2 are references to hashes, while $myhash3
doesn't exist, and %myhash3 is a normal hash?

--Ala

"Ala Qumsieh" <> wrote:
> "Malcolm Dew-Jones" <> wrote in message
> news:...
>
> > I prefer
> > $my_hash{$item}
> >
> > but someone else might prefer
> >
> > $my_hash->{$item}
>
> errr .. those two are not the same.

<snip>

> > $myhash1->{$item}
> > $myhash2->{$item}
> > $myhash3{$item} # huh, why is this different?
>
> Maybe because $myhash1 and $myhash2 are references to hashes, while $myhash3
> doesn't exist, and %myhash3 is a normal hash?

You're missing the point. If you want to use a hash, you can either
create it thus

my %hash = (
key => $value,
);

and use it thus

$hash{key};

or you can create it thus

my $hash = {
key => $value;
};

and use it thus

$hash->{key};

.. Which you choose makes no difference to the outcome of the program.

Ben

--
If I were a butterfly I'd live for a day, / I would be free, just blowing away.
This cruel country has driven me down / Teased me and lied, teased me and lied.
I've only sad stories to tell to this town: / My dreams have withered and died.
<=>=<=>=<=>=<=>=<=>=<=>=<=>=<=>=<=>=<=>=<=> (Kate Rusby)