[26067] in Perl-Users-Digest
Perl-Users Digest, Issue: 8272 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Jul 23 21:05:21 2005
Date: Sat, 23 Jul 2005 18:05:03 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 23 Jul 2005 Volume: 10 Number: 8272
Today's topics:
Re: copy contructor (Anno Siegel)
Re: copy contructor <abigail@abigail.nl>
Re: Mod_Perl vs PHP in memory, speed, varibles <nntp@alexa.com>
Re: Mod_Perl vs PHP in memory, speed, varibles <noreply@gunnar.cc>
posting an array <usenet@NOSPAM.obantec.net>
Re: posting an array <spam-block-@-SEE-MY-SIG.com>
Re: posting an array <noreply@gunnar.cc>
Re: Regex (?(?{CODE})) has too many branches <spam-block-@-SEE-MY-SIG.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 23 Jul 2005 18:52:16 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: copy contructor
Message-Id: <dbu3l0$nf3$1@mamenchi.zrz.TU-Berlin.DE>
Abigail <abigail@abigail.nl> wrote in comp.lang.perl.misc:
> Anno Siegel (anno4000@lublin.zrz.tu-berlin.de) wrote on MMMMCCCXLI
> September MCMXCIII in <URL:news:dbl9pb$g3r$2@mamenchi.zrz.TU-Berlin.DE>:
>
> > [[ Snipped for brevity ]]
>
>
> Here's how I would subclass Angry::Snake. Note that I subclass the
> original Angry::Snake, without requiring it to have an "accessor".
Ah, but in my book (that would be a little paper I'm writing about
inheritance in Perl) it *has* an accessor. Any method that accesses the
object by de-referencing the object is an accessor, whether it returns
the value to the caller or does something else with it. That would make
->poke_it_with_a_stick an accessor. A field accessor in the usual
sense is just a special case. In most mainstream OO languages there
are no accessors except field accessors, so the two notions coincide,
but Perl is different.
That's just terminology. Maybe I should think it over and find a better
term. But what can you call a method whose distinguishing property is that
it accesses the object?
> package Angry::Snake;
>
> sub new {
> bless \do {my $c = int rand 5} => shift;
> }
>
> sub poke_it_with_a_stick {
> my $snake = shift;
> $snake -> attack if $$snake -- < 0;
> }
>
> sub attack { ... }
>
>
>
> package Sleepy::Snake; {
> use Scalar::Util qw 'refaddr';
>
> our @ISA = qw /Angry::Snake/;
>
> my %sleepiness; # Store the attribute in a lexical variable.
>
> sub set_sleepiness {
> my $snake = shift;
> $sleepiness {refaddr $snake} = shift;
> $snake;
> }
> sub sleepiness {
> my $snake = shift;
> $sleepiness {refaddr $snake};
> }
>
> sub poke_it_with_a_stick {
> my $snake = shift;
> $snake -> SUPER::poke_it_with_a_stick
> if rand > $snake -> sleepiness;
> }
>
> sub DESTROY {
> my $snake = shift;
> delete $sleepiness {refaddr $snake};
> }
> }
>
> package main;
>
> my $snake = Sleepy::Snake -> new -> set_sleepiness (0.5);
>
>
> Note that Sleepy::Snake doesn't have its own constructor.
No, it can't. One of the tenets about Perl inheritance is "If you
inherit an accessor, you must also inherit ->new", which is what happens
here. Inherit as opposed to override.
Like all short formulas about complex fields (except exp(i*pi) = -1, hehe),
it is wrong. You can override ->new, provided you call the base class'
->new to create the object. Your objects must be structurally the same
as those of the base class if you want the base class accessors to work
on them. Put like that it's a truism.
However, in package Sleepy::Snake it would be safe to override ->new
sub new { shift()->SUPER::new->set_sleepiness( 0.5) }
so as not to create snakes with undefined sleepiness.
> Nor does it rely
> on how Angry::Snake has been implemented in any way. It doesn't require
> its super class to make accessors available. It doesn't force anything
> on a potential subclass either.
Quite so, it carries itself the full weight of inheriting from the
deliberately inheritance-unfriendly Angry::Snake. The weight is the
somewhat unusual implementation. It shows again that inheritance in
Perl doesn't come for free. Someone must support it, the base class
and/or the inheriting class.
So "Inside-out" is what you call them. (I've read some more of the thread,
but wanted to reply with your code in sight.) It's an ingenious answer
to the question: How can I assign additional data (fields) to an object when
I'm not allowed to change its structure?
I suppose you are using Scalar::Util::refaddr because stringification
may be overloaded for the base class. Otherwise the stringified object
would serve as well. I have used overload::StrVal for the purpose.
On re-reading perldoc overload I see that there is now a pointer to
Scalar::Util::refaddr.
Just out of spite, below is yet another way to inherit poke_it_with-
_a_stick from an (unchanged) Angry::Snake. It uses de-reference
overloading to persuade the base class to access Sleepy::Snake objects
in a special way. Overloading every possible kind of de-reference makes
sure it continues to work when Angry::Snake changes its implementation.
It is more heavy handed than the elegant inside-out objects, and it inhibits
further inheritance in a major way. Overloading de-reference is bad for
inheritance, carpet-bombing it over all types, as I do here, is worse.
The merit of this way, if any, is the standard implementation of
Sleepy::Snake as a typical hash-as-a-struct.
package Sleepy::Snake;
use base 'Angry::Snake';
use overload map { $_ => 'snake' } qw( ${} @{} %{} &{} *{});
sub new {
my $class = shift;
bless {
sleepiness => 0.5,
snake => Angry::Snake->SUPER::new,
}, $class;
}
sub set_sleepiness { $_[ 0]->{ sleepiness} = $_[ 1]; shift }
sub sleepiness { $_[ 0]->{ sleepiness} }
# we're the ->{ snake} field for Angry::Snake, ourselves for
# everyone else
sub snake { caller eq 'Angry::Snake' ? $_[ 0]->{ snake} : $_[ 0] }
sub poke_it_with_a_stick {
my $snake = shift;
$snake -> SUPER::poke_it_with_a_stick if rand > $snake -> sleepiness;
}
__END__
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: 23 Jul 2005 20:25:21 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: copy contructor
Message-Id: <slrnde59tg.7fo.abigail@alexandra.abigail.nl>
Anno Siegel (anno4000@lublin.zrz.tu-berlin.de) wrote on MMMMCCCXLIV
September MCMXCIII in <URL:news:dbu3l0$nf3$1@mamenchi.zrz.TU-Berlin.DE>:
{} Abigail <abigail@abigail.nl> wrote in comp.lang.perl.misc:
{} > Anno Siegel (anno4000@lublin.zrz.tu-berlin.de) wrote on MMMMCCCXLI
{} > September MCMXCIII in <URL:news:dbl9pb$g3r$2@mamenchi.zrz.TU-Berlin.DE>:
{} >
{} > > [[ Snipped for brevity ]]
{} >
{} >
{} > Here's how I would subclass Angry::Snake. Note that I subclass the
{} > original Angry::Snake, without requiring it to have an "accessor".
{}
{} Ah, but in my book (that would be a little paper I'm writing about
{} inheritance in Perl) it *has* an accessor. Any method that accesses the
{} object by de-referencing the object is an accessor, whether it returns
{} the value to the caller or does something else with it. That would make
{} ->poke_it_with_a_stick an accessor. A field accessor in the usual
{} sense is just a special case. In most mainstream OO languages there
{} are no accessors except field accessors, so the two notions coincide,
{} but Perl is different.
Oh, it has an accessor allright. Whether or not the super class has
an accessor is not important. Or rather, it's irrelevant. And that's
(IMO) the beauty of Inside-Out Objects. It's _irrelevant_ whether the
superclass has accessors. Or attributes/fields. Or how it stores them.
How the superclass is implemented does not matter - all that matters
is its API. And the whole implementation can change, accessors can turn
into non-accessors, or visa versa, if the API remains the same, there's
no need to update the inheriting class.
{} That's just terminology. Maybe I should think it over and find a better
{} term. But what can you call a method whose distinguishing property is that
{} it accesses the object?
I don't really care how you call them. I don't think a different term from
them is important. In fact, when I call methods in a class, I do not want
to have to know whether it's an accessor or not. When I look to a class
from anywhere but the class itself, all I should see is methods. If I
need to know (perhaps to do something different) that a method is an
"accessor", something is wrong. IMO, it breaks encapsulation, and OO with
broken encapsulation is no fun at all.
{} > Note that Sleepy::Snake doesn't have its own constructor.
{}
{} No, it can't. One of the tenets about Perl inheritance is "If you
{} inherit an accessor, you must also inherit ->new", which is what happens
{} here. Inherit as opposed to override.
Sure it can have its own constructor. I just decided not to. I prefer
not to configure an object (that is, setting attribute values) in a
constructor because that makes multiple inheritance a real pain in the
ass, so I prefer to only have constructors in classes that don't inherit
other classes, and such constructors should only return the blessed
reference, and do not anything else. Having said, if I were to create
a constructor for the Sleepy::Snake class, I'd do it like this:
sub new {
my $snake = Angry::Snake -> new; # Let the class set itself up
# in whatever way it pleases.
$sleepiness {refaddr $snake} = 0.5; # Default value.
bless $snake => shift; # Bless it to our class.
}
{} Like all short formulas about complex fields (except exp(i*pi) = -1, hehe),
{} it is wrong. You can override ->new, provided you call the base class'
{} ->new to create the object. Your objects must be structurally the same
{} as those of the base class if you want the base class accessors to work
{} on them. Put like that it's a truism.
Yes. But that's the beauty of Inside-Out Objects. It doesn't care what
structure the super class has, because it doesn't use the structure at
all. All it needs is the memory address.
{} However, in package Sleepy::Snake it would be safe to override ->new
{}
{} sub new { shift()->SUPER::new->set_sleepiness( 0.5) }
{}
{} so as not to create snakes with undefined sleepiness.
That works as well as the constructor I used above. But it makes
multiple inheritance a lot harder.
{} > Nor does it rely
{} > on how Angry::Snake has been implemented in any way. It doesn't require
{} > its super class to make accessors available. It doesn't force anything
{} > on a potential subclass either.
{}
{} Quite so, it carries itself the full weight of inheriting from the
{} deliberately inheritance-unfriendly Angry::Snake. The weight is the
{} somewhat unusual implementation. It shows again that inheritance in
{} Perl doesn't come for free. Someone must support it, the base class
{} and/or the inheriting class.
{}
{} So "Inside-out" is what you call them. (I've read some more of the thread,
{} but wanted to reply with your code in sight.) It's an ingenious answer
{} to the question: How can I assign additional data (fields) to an object when
{} I'm not allowed to change its structure?
It solves two of the three problems I have traditional (hash based) objects
in Perl:
* No encapsulation.
* No 'use strict' benefits when accessing object attributes.
But those are the two biggest problems.
\begin{side-remark}
My third problem is that getting to object attributes takes too much typing.
For instance, in a non-OO world, adding elements to an array is written as
follows:
push @array => 'one', 'two', 'three';
Quite straight forward. But in OO, we have something like:
push @{$_ [0] -> {array}} => 'one', 'two', 'three'; # Or
push @{${$_ [0]} {array}} => 'one', 'two', 'three';
Even with Inside-Out Objects, we have:
push @{$array {refaddr $_ [0]}} => 'one', 'two', 'three';
But I've fixed that as well. With Lexical::Attributes, I just write:
push @.array => 'one', 'two', 'three';
But that's for a different thread.
\end{side-remark}
{} I suppose you are using Scalar::Util::refaddr because stringification
{} may be overloaded for the base class. Otherwise the stringified object
{} would serve as well. I have used overload::StrVal for the purpose.
{} On re-reading perldoc overload I see that there is now a pointer to
{} Scalar::Util::refaddr.
Indeed, overloading stringification is a problem. Reblessing to a
different class is a problem as well if you use the stringified form of
the object to index. A minor benefit is that C<refaddr $obj> is shorter
string than C<"$obj">, so storage of keys should be somewhat less,
and the calculation of the hash value should take a fraction less.
{} Just out of spite, below is yet another way to inherit poke_it_with-
{} _a_stick from an (unchanged) Angry::Snake.
;-)
Abigail
--
perl -e '$a = q 94a75737420616e6f74686572205065726c204861636b65720a9 and
${qq$\x5F$} = q 97265646f9 and s g..g;
qq e\x63\x68\x72\x20\x30\x78$&eggee;
{eval if $a =~ s e..eqq qprint chr 0x$& and \x71\x20\x71\x71qeexcess}'
------------------------------
Date: Sat, 23 Jul 2005 16:50:36 -0400
From: "nntp" <nntp@alexa.com>
Subject: Re: Mod_Perl vs PHP in memory, speed, varibles
Message-Id: <9JWdneovVpoAMH_fRVn-1w@rogers.com>
> nntp wrote:
> > I tried mod_perl. It is too troublesome. Many old scripts stopped
running.
> > Even those running eat memory like crazy.
>
> Did you study this document about porting CGI scripts to mod_perl:
> http://perl.apache.org/docs/1.0/guide/porting.html
That does not work. Even with PerlRun, there are huge memory leak.
>
> > I wonder why mod_php does not have the problems in mod_perl, such as
memory
> > hog, varible initialization etc.
>
> The perceived difference may have something to do with the fact that
> while there are many old CGI scripts that were never designed with
> mod_perl in mind, PHP scripts that weren't designed with mod_php in mind
> are of rare occurrence.
PHP programmers don't need to worry about initializtion, and the PHP itself
will clear all memory after usage. I don't understand why mod_perl can not
do it. This really kills perl in majority. Anyone can write php, but only
few can write mod_perl.
------------------------------
Date: Sat, 23 Jul 2005 23:08:47 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Mod_Perl vs PHP in memory, speed, varibles
Message-Id: <3kfpv1FtpocnU1@individual.net>
nntp wrote:
> Gunnar Hjalmarsson wrote:
>> Did you study this document about porting CGI scripts to mod_perl:
>> http://perl.apache.org/docs/1.0/guide/porting.html
>
> That does not work.
I should have realized that you are just a pitiful troll. Show us some
hard evidence supporting your claim, or else there is no reason to talk.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Sat, 23 Jul 2005 19:34:10 +0100
From: "Mark D Smith" <usenet@NOSPAM.obantec.net>
Subject: posting an array
Message-Id: <42e28daa$0$24867$da0feed9@news.zen.co.uk>
Hi
i am posting a hidden values called accounts which is a number of usernames
pushed to an array.
print "<input type=hidden name=accounts value=\"@accounts\">";
the page that receives the data should be able to unpack the array but i am
having problems
&ReadParse();
foreach $line(@in) {
print "$line <br>\n";
}
shows accounts=username+username_001+username_002+username_003
as expected
but
$cnt=0;
@accounts = $in{'accounts'};
foreach $line(@accounts) {
print "$line<br>\n";
$cnt++;
}
print $cnt;
username username_001 username_002 username_003
1
all on 1 line, not 1 line for each value in the array.
what have i missed
Mark
------------------------------
Date: Sat, 23 Jul 2005 20:46:56 +0100
From: James Taylor <spam-block-@-SEE-MY-SIG.com>
Subject: Re: posting an array
Message-Id: <ant231956566fNdQ@riscpc.jtnet>
In article <42e28daa$0$24867$da0feed9@news.zen.co.uk>,
Mark D Smith <usenet@NOSPAM.obantec.net> wrote:
>
> $cnt=0;
> @accounts = $in{'accounts'};
> foreach $line(@accounts) {
> print "$line<br>\n";
> $cnt++;
> }
> print $cnt;
>
> username username_001 username_002 username_003
> 1
>
> all on 1 line, not 1 line for each value in the array.
>
> what have i missed
It looks like $in{'accounts'} is a single line of text. It
gets assigned to @accounts which is then just a single item
array. Then the foreach loop only goes round once because
there is only one item in the @accounts array.
In order to process the space separated list of usernames
one at a time you must first convert the single line of text
to a list. The standard way of doing this would be to use
the 'split' function.
@accounts = split / /, $in{'accounts'};
Read up on the use of split here:
http://www.perldoc.com/perl5.6/pod/func/split.html
or by typing:
perldoc -f split
--
James Taylor, London, UK PGP key: 3FBE1BF9
To protect against spam, the address in the "From:" header is not valid.
In any case, you should reply to the group so that everyone can benefit.
If you must send me a private email, use james at oakseed demon co uk.
------------------------------
Date: Sat, 23 Jul 2005 21:50:53 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: posting an array
Message-Id: <3kflcuFtuh2fU1@individual.net>
Mark D Smith wrote:
> i am posting a hidden values called accounts which is a number of usernames
> pushed to an array.
>
> print "<input type=hidden name=accounts value=\"@accounts\">";
>
> the page that receives the data should be able to unpack the array but i am
> having problems
>
> &ReadParse();
>
> foreach $line(@in) {
> print "$line <br>\n";
> }
>
> shows accounts=username+username_001+username_002+username_003
> as expected
>
> but
>
> $cnt=0;
> @accounts = $in{'accounts'};
> foreach $line(@accounts) {
> print "$line<br>\n";
> $cnt++;
> }
> print $cnt;
>
> username username_001 username_002 username_003
> 1
>
> all on 1 line, not 1 line for each value in the array.
>
> what have i missed
You seem to have missed a few things. First, what you post via a form
control is a string, not a list.
An array, such as
my @accounts = qw/name1 name2 name3/;
returns a string with the elements separated with spaces and
concatenated, if you surround it with double quotes.
If the usernames don't contain space characters, you can try
@accounts = split ' ', $in{'accounts'};
Another thing is that your Perl coding style seems to be outdated.
Please make it a habit to my() declare the variables and enable
strictures and warnings. Also, it may be a good idea to start using the
standard module CGI.pm instead of cgi-lib.pl (or whatever code you are
referring to with "&ReadParse();").
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Sat, 23 Jul 2005 19:57:46 +0100
From: James Taylor <spam-block-@-SEE-MY-SIG.com>
Subject: Re: Regex (?(?{CODE})) has too many branches
Message-Id: <ant231846f00fNdQ@riscpc.jtnet>
In article <slrnde4g04.jr7.tadmc@magna.augustmail.com>,
Tad McClellan <tadmc@augustmail.com> wrote:
>
> James Taylor wrote:
> >
> > <*whoosh*> That's the sound of that paragraph going way over
> > my head. I assume that <!INCLUDE> is an SGML thing.
>
> Yes, it is called a "marked section".
>
> > Is it also relevant to HTML?
>
> Since HTML is an "SGML application", all SGML things apply
> to HTML things, despite the fact that the most common
> processors (ie. browsers) are not spec-compliant.
Well, from what I was able to find on this matter, opinion seems
to favour the view that HTML is, for practical purposes, only
a subset of SGML. Marked sections such as <![INCLUDE [] ]>
appear to be specifically depreciated/discouraged in HTML.
Publishing HTML with SGML includes in it is asking for trouble.
> > Abigail wrote:
> > >
> > > an attribute might contain '<!--', and another attribute might
> > > contain '-->'. What's in between is not an HTML comment.
> >
> > Shocking!
>
> Not for folks that pay attention to specifications.
No, my point is that I would find it shocking to see HTML
written like that because, whether the author is an SGML
expert or not, it demonstrates a decision not to write
robust HTML likely to work in every browser, or possibly a
blindness to such practicalities. We live in a world full of
far too much fragile HTML as it is, and we should expect
higher standards of interoperability for the sake of our
freedom. There is a social responsibility to be as inclusive
as possible with HTML markup that few website authors seem
to care about. For a website author to defiantly claim
"my site is SGML compliant so it must be your browser that's
broken" is as ignorant as him saying "my site works in the
latest version of MSIE, so I don't care about your browser".
I could get really cross with people like that because, not
only are they turning the web into shit for those of us not
using the latest browser, but they are also impoverishing
all minority platforms to the benefit of monopolies which
have sufficient finances to keep up with the ever increasing
development costs. Minority platforms continue to die away
as the monopoly becomes ever stronger. It's like watching
people merrily destroying a rainforest to replace its rich
diversity with a rat infested dump. Grrr... I could get all
RMS about this. We're raising the bar of complexity for
little gain and throwing away our technological freedoms
without thinking. Soon we'll all be using the same bloated
buggy browser and talking in NewSpeak!
> HTML is _data_, not code.
I realise that HTML is not a programming language, but the
use of the term "code" to describe it is fairly widely used
and understood. I was lax, perhaps, but pedantry tends to
have a greater negative effect on discourse.
> attempting to use regexes rather than a real parser is
> what's complicating things.
The HTML parsers I've looked at would all involve more work
to use for this specific task and would be slower to run too.
This is what I've settled on, and it works quite well:
my $table;
while ($page =~ m{ (?> <table\b [^>]* > (.*?) </table> ) }xsig) {
$table = $1;
last if $table !~ /<table\b/i &&
$table =~ /class="whiteHeading"/i;
}
Thanks to all.
--
James Taylor, London, UK PGP key: 3FBE1BF9
To protect against spam, the address in the "From:" header is not valid.
In any case, you should reply to the group so that everyone can benefit.
If you must send me a private email, use james at oakseed demon co uk.
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 8272
***************************************
