Front page | perl.perl5.porters |
Postings from March 2008
Mark Mielke wrote: > David Nicol wrote: >> On Fri, Mar 21, 2008 at 12:59 PM, Mark Mielke <mark@mark.mielke.cc> >> wrote: >> >>> seem to be something that absolutely must change), I believe the true >>> problem here is that die seems to be pass by reference, and that local >>> is restoring the value to undef (or whatever it was before) before >>> $@ is >>> made available to the caller. >>> >> >> no that's not it but it is a red herring -- I would like to revise >> the proposed >> addition of this issue to the eval documentation to but double-quotes >> around the $@ in the commented-out line in the example code. >> >> >> > > That's not a real solution - what about if $@ is an object? > > Effectively you are changing pass by reference to pass by string copy > - which is good for probably 95%+ cases. As I said, the problem is > pass by reference. Just had a thought - perhaps some Perl people don't know what I mean by pass by reference. That's the only reason I can think of why Dave might have called my claim that pass by reference was the real problem a "red herring", but then suggest pass by copy as a solution (thereby agreeing with me). Pass by reference doesn't mean Perl \ operator or Perl language level references. I mean that the $@ is bound to an SV, and this SV is passed by C reference to the caller, however, local replaces the value of the C reference with the old value. David's suggestion of "$@" causes the $@ to be evaluated as a string, and a COPY of it be taken, returning it to the caller as a new string. Does this explain it Dave? Cheers, mark -- Mark Mielke <mark@mielke.cc>Thread Previous | Thread Next