You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by "Jeffrey W. Baker" <jw...@acm.org> on 2000/05/03 19:36:59 UTC
Why does $r->print() dereference its arguments?
Apache::print() dereferences its arguments. For example, this code:
my $foo = "bar";
$r->print(\$foo);
prints "bar" instead of the expected SCALAR(0xDEADBEEF). Can anyone
explain the purpose of this behavior, or is it a misfeature? In my case,
this is not the desired behavior.
-jwb
Re: Why does $r->print() dereference its arguments?
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Jeffrey" == Jeffrey W Baker <jw...@acm.org> writes:
Jeffrey> Apache::print() dereferences its arguments. For example, this code:
Jeffrey> my $foo = "bar";
Jeffrey> $r->print(\$foo);
Jeffrey> prints "bar" instead of the expected SCALAR(0xDEADBEEF). Can anyone
Jeffrey> explain the purpose of this behavior, or is it a misfeature? In my case,
Jeffrey> this is not the desired behavior.
You can always call $r->print(\\$foo); :)
As in, $r->print(map { \$_ } @list) will work as your print, always.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Why does $r->print() dereference its arguments?
Posted by Gunther Birznieks <gu...@extropia.com>.
At 11:56 AM 5/3/00 -0700, Jeffrey W. Baker wrote:
>On 3 May 2000, Chip Turner wrote:
>
> > "Jeffrey W. Baker" <jw...@acm.org> writes:
> >
> > > Apache::print() dereferences its arguments. For example, this code:
> > >
> > > my $foo = "bar";
> > > $r->print(\$foo);
> > >
> > > prints "bar" instead of the expected SCALAR(0xDEADBEEF). Can anyone
> > > explain the purpose of this behavior, or is it a misfeature? In my case,
> > > this is not the desired behavior.
> >
> > If I recall correctly, this is a performance issue. If you have a
> > large string you want to print, sending a reference will result in
> > less data copying etc. I don't know how much it pays off, but it is
> > an intended effect.
> >
> > You could try something like:
> >
> > $r->print("@{[\$foo]}");
>
>Or I could just do $r->print(scalar(\$foo));, but that's not my point. My
>point is Ewwwwwwwwwwwwwwwwwww. I just don't like the overloaded
>interface. Does $r->print() take scalars, or references? If it takes
>scalars, it shouldn't be dereferencing them. If there is a performance
>need for passing references around instead of copying strings, that should
>be a different method, perhaps print_ref(). It just seems more clean to
>me. Is my mindset too C?
I prefer overloading that is documented. It makes things a lot easier to
remember one method name.
Otherwise, you have to be an expert who remembers common idioms like _ref
for references... otherwise, people would argue should it be called
ref_print, reference_print, print_ref, print_as_ref... Programmers have all
sorts of weird ways to name functions (if you've delved into other people's
source code) which I hate.
HOWEVER, I think a good argument for NOT overloading print() in this
particular case is that it is taking over CORE::print. This is contrary to
documented Perl behavior and is not backwards compatible then right? If
this is the case, then that seems suboptimal.
Also, I guess I could see the point that since print() is so well defined
in the core Perl, that people might expect Apache's print to operate
identically even if it is called directly. And therefore, the behavior
should not change from CORE::print anyway.
So in summary, I think I am saying that I vote to support your desire
reluctantly because I am generally a fan of overloading (but not in this
case if I am interpreting the facts correctly).
Of course, it may be too late because there may be a load of code that is
dependent on this "Performance improvment". So it may be a moot point anyway.
Later,
Gunther
__________________________________________________
Gunther Birznieks (gunther.birznieks@extropia.com)
Extropia - The Web Technology Company
http://www.extropia.com/
Re: Why does $r->print() dereference its arguments?
Posted by "Jeffrey W. Baker" <jw...@acm.org>.
On 3 May 2000, Chip Turner wrote:
> "Jeffrey W. Baker" <jw...@acm.org> writes:
>
> > Apache::print() dereferences its arguments. For example, this code:
> >
> > my $foo = "bar";
> > $r->print(\$foo);
> >
> > prints "bar" instead of the expected SCALAR(0xDEADBEEF). Can anyone
> > explain the purpose of this behavior, or is it a misfeature? In my case,
> > this is not the desired behavior.
>
> If I recall correctly, this is a performance issue. If you have a
> large string you want to print, sending a reference will result in
> less data copying etc. I don't know how much it pays off, but it is
> an intended effect.
>
> You could try something like:
>
> $r->print("@{[\$foo]}");
Or I could just do $r->print(scalar(\$foo));, but that's not my point. My
point is Ewwwwwwwwwwwwwwwwwww. I just don't like the overloaded
interface. Does $r->print() take scalars, or references? If it takes
scalars, it shouldn't be dereferencing them. If there is a performance
need for passing references around instead of copying strings, that should
be a different method, perhaps print_ref(). It just seems more clean to
me. Is my mindset too C?
-jwb
Re: Why does $r->print() dereference its arguments?
Posted by Chip Turner <ch...@zfx.com>.
"Jeffrey W. Baker" <jw...@acm.org> writes:
> Apache::print() dereferences its arguments. For example, this code:
>
> my $foo = "bar";
> $r->print(\$foo);
>
> prints "bar" instead of the expected SCALAR(0xDEADBEEF). Can anyone
> explain the purpose of this behavior, or is it a misfeature? In my case,
> this is not the desired behavior.
If I recall correctly, this is a performance issue. If you have a
large string you want to print, sending a reference will result in
less data copying etc. I don't know how much it pays off, but it is
an intended effect.
You could try something like:
$r->print("@{[\$foo]}");
Chip
--
Chip Turner chip@ZFx.com
ZFx, Inc. www.zfx.com
PGP key available at wwwkeys.us.pgp.net
Re: Why does $r->print() dereference its arguments?
Posted by Doug MacEachern <do...@covalent.net>.
On Thu, 4 May 2000, Jeffrey W. Baker wrote:
> Not strictly for debugging, but for introspection. I was toying with
> a module that pokes around inside the perlguts of a running mod_perl
> server and makes some nice displays out of them. Nothing for
> production/money mind you, just amusement.
i did have reservations when adding the stunt, but i figured the chances
of somebody printing a $reference on purpose, which was not interpolated
in another string already were pretty slim. seems you're the first to
notice in the two years since the "feature" was added :)
btw, just to be clear, $strings passed to $r->print() are not copied, they
are passed by reference, just like any argument to a subroutine. but
most subroutines copy the arguments into their own variables, e.g.:
sub foo {
my ($header, $body, $footer) = @_;
so the idea was that you could pass around references to strings, which
end up being passed to $r->print, without having to worry about
dereferencing.
> Here is a patch I made against the documentation in Apache.pm. Actually,
> I had to attach it because it was wrapping.
thanks!
Re: Why does $r->print() dereference its arguments?
Posted by "Jeffrey W. Baker" <jw...@acm.org>.
On Wed, 3 May 2000, Doug MacEachern wrote:
> On Wed, 3 May 2000, Jeffrey W. Baker wrote:
>
> > Apache::print() dereferences its arguments. For example, this code:
> >
> > my $foo = "bar";
> > $r->print(\$foo);
> >
> > prints "bar" instead of the expected SCALAR(0xDEADBEEF). Can anyone
> > explain the purpose of this behavior, or is it a misfeature? In my case,
> > this is not the desired behavior.
>
> it only pulls that stunt for strings. assuming you're only printing the
> reference for debugging purposes, just stringify it first:
>
> my $foo = \"bar";
>
> print "$foo";
>
> or, geoff's trick:
>
> my $foo = "bar";
>
> print \$foo . "";
>
> do you need to avoid this feature for something other than debugging?
Not strictly for debugging, but for introspection. I was toying with
a module that pokes around inside the perlguts of a running mod_perl
server and makes some nice displays out of them. Nothing for
production/money mind you, just amusement.
Here is a patch I made against the documentation in Apache.pm. Actually,
I had to attach it because it was wrapping.
Regards,
Jeffrey
Re: Why does $r->print() dereference its arguments?
Posted by Doug MacEachern <do...@covalent.net>.
On Wed, 3 May 2000, Jeffrey W. Baker wrote:
> Apache::print() dereferences its arguments. For example, this code:
>
> my $foo = "bar";
> $r->print(\$foo);
>
> prints "bar" instead of the expected SCALAR(0xDEADBEEF). Can anyone
> explain the purpose of this behavior, or is it a misfeature? In my case,
> this is not the desired behavior.
it only pulls that stunt for strings. assuming you're only printing the
reference for debugging purposes, just stringify it first:
my $foo = \"bar";
print "$foo";
or, geoff's trick:
my $foo = "bar";
print \$foo . "";
do you need to avoid this feature for something other than debugging?
Re: Why does $r->print() dereference its arguments?
Posted by Stas Bekman <sb...@stason.org>.
On Wed, 3 May 2000, Jeffrey W. Baker wrote:
> Apache::print() dereferences its arguments. For example, this code:
>
> my $foo = "bar";
> $r->print(\$foo);
>
> prints "bar" instead of the expected SCALAR(0xDEADBEEF). Can anyone
> explain the purpose of this behavior, or is it a misfeature? In my case,
> this is not the desired behavior.
That's a performance improvement, see:
http://perl.apache.org/guide/porting.html#Apache_print_and_CORE_print_
______________________________________________________________________
Stas Bekman | JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ | mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org | http://perl.org http://stason.org/TULARC/
http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org
----------------------------------------------------------------------