[12082] in Perl-Users-Digest
Perl-Users Digest, Issue: 5682 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun May 16 06:07:18 1999
Date: Sun, 16 May 99 03:00:16 -0700
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 16 May 1999 Volume: 8 Number: 5682
Today's topics:
[Fwd: my hands are tied] <gbartels@xli.com>
Re: Perl "constructors" (Sam Holden)
Re: Perl "constructors" <rra@stanford.edu>
Re: Perl "constructors" armchair@my-dejanews.com
Re: Perl "constructors" <rra@stanford.edu>
Re: Perl "constructors" <rra@stanford.edu>
Re: Perl "constructors" armchair@my-dejanews.com
Re: Perl "constructors" armchair@my-dejanews.com
Re: Perl "constructors" <rra@stanford.edu>
Re: Perl "constructors" armchair@my-dejanews.com
Re: Perl "constructors" (Alan Curry)
Re: Perl "constructors" armchair@my-dejanews.com
Re: Perl "constructors" <rra@stanford.edu>
Please Help.??? <JK@sandwell98.free-online.co.uk>
Re: Please Help.??? <rra@stanford.edu>
problem w/perl cgi script & background image (rcastro)
Re: Saving regularly a web page <amig@csi.com>
Re: Saving regularly a web page <amig@csi.com>
Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Desig (Ran)
Re: TROLL ALERT (Re: Perl "constructors") <rra@stanford.edu>
Special: Digest Administrivia (Last modified: 12 Dec 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 11 May 1999 21:15:52 +0100
From: Greg Bartels <gbartels@xli.com>
Subject: [Fwd: my hands are tied]
Message-Id: <780A83616B05D31196800020484025001B251D@SEUBPEBAS54>
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_000_01BE9F7A.EA5CD432
Content-Type: text/plain;
charset="iso-8859-1"
Greg Bartels wrote:
> this works:
> my $first; tie $first, 'stoplight', \$first, 4;
>
> sub TIESCALAR # in stoplight.pm looks like this
> {
> my ($class,$ref,$value) =@_;
> my $r_hash = {
> 'ref' => $ref,
> 'value'=>$value };
> return bless $r_hash, $class;
> }
>
> The problem is that
> my $first; tie $first, 'stoplight', \$first, 4;
> is about as ugly as you can get.
>
> is there anyway to write a subroutine that I could
> say something like:
> my $first = magic_routine(4);
> and it figures out the rest?
> i.e. $first is a scalar tied to 'stoplight' package, initialized to 4,
> and
> a reference to the scalar is stored in the object.
> something like:
>
> sub magic_routine
> {
> my($initial_value) = @_:
> my $scalar;
> tie $scalar, 'stoplight', \$signal, $initial_value;
> my $r_hash = {
> 'ref' => \$signal,
> 'value' => $value };
> return bless $r_hash, 'stoplight';
> }
>
> in yet other words, how can I write my own 'tie' routine?
>
> my_tie( my $first, 4);
>
> how does tie do its magic?
>
> gbartels@xli.com
------_=_NextPart_000_01BE9F7A.EA5CD432
Content-Type: message/rfc822
Newsgroups: comp.lang.perl.moderated
From: Greg Bartels <gbartels@xli.com>
Subject: my hands are tied
Message-ID: <373884E1.A8385FFE@xli.com>
Sender: Greg Bartels <gbartels@xli.com>
Date: Tue, 11 May 1999 20:28:33 +0100
MIME-Version: 1.0
Lines: 16
X-Newsreader: Microsoft (R) Exchange Internet News Service Version 5.5.2448.0
Content-Type: text/plain
this works:
my $first; tie $first, 'stoplight', \$first, 4;
sub TIESCALAR # in stoplight.pm looks like this
{
my ($class,$ref,$value) =@_;
my $r_hash = {
'ref' => $ref,
'value'=>$value };
return bless $r_hash, $class;
}
The problem is that
my $first; tie $first, 'stoplight', \$first, 4;
is about as ugly as you can get.
is there anyway to write a subroutine that I could
say something like:
my $first = magic_routine(4);
and it figures out the rest?
i.e. $first is a scalar tied to 'stoplight' package, initialized to 4,
and
a reference to the scalar is stored in the object.
something like:
sub magic_routine
{
my($initial_value) = @_:
my $scalar;
tie $scalar, 'stoplight', \$signal, $initial_value;
my $r_hash = {
'ref' => \$signal,
'value' => $value };
return bless $r_hash, 'stoplight';
}
in yet other words, how can I write my own 'tie' routine?
my_tie( my $first, 4);
how does tie do its magic?
gbartels@xli.com
------_=_NextPart_000_01BE9F7A.EA5CD432--
------------------------------
Date: 16 May 1999 08:06:26 GMT
From: sholden@pgrad.cs.usyd.edu.au (Sam Holden)
Subject: Re: Perl "constructors"
Message-Id: <slrn7jsv42.bit.sholden@pgrad.cs.usyd.edu.au>
On Sun, 16 May 1999 07:48:26 GMT, armchair@my-dejanews.com wrote:
>In article <ylyaip4zsm.fsf@windlord.stanford.edu>,
> Russ Allbery <rra@stanford.edu> wrote:
>> armchair <armchair@my-dejanews.com> writes:
>>
>> > And what does your code look like?
>>
>> > #constructor...
>> > if ( success )
>> > { return bless a; } else { return 0; }
>>
>> Nope. On failure, it calls die.
>
>So, that gives us:
>if ( success )
>{ return bless a } else { die "failed in constructor because of zz"; }
>
>That solves the problem of not checking a return code, but not all
>constructor failure would be fatal errors would they? What if the
>operation performed was just one of several the user could attempt in
>that session and they were quite willing to wait until later, or
>complete their other tasks and just leave that item incomplete?
Then they catch the exception that die throws and deal with it.
As done in the code below with eval...
>> > my $reference = myclass->new();
>> > if ( $reference == 0 )
>> > {
>> > print "constructor failed\n";
>> > }
>>
>> > Correct?
>>
>> No, if I'm calling a constructor that needs to be able to throw
>> exceptions, I do:
>>
>> my $object;
>> eval { $object = My::Class->new };
>> if ($@) {
>> print "Constructor failed: $@\n";
>> }
>>
>
>
>Well eval() and $@ are beyond me at this point, but it does look like
>exception handling of a fashion.
eval is try, if is catch...
--
Sam
the Emacs editor is horrible
--Linus Torvalds
------------------------------
Date: 16 May 1999 01:08:49 -0700
From: Russ Allbery <rra@stanford.edu>
Subject: Re: Perl "constructors"
Message-Id: <ylwvy91lny.fsf@windlord.stanford.edu>
Alan Curry <pacman@defiant.cqc.com> writes:
> So the fact that perl completely ignores memory allocation issues is a
> _feature_?
Yes.
Perl is a garbage-collected language that handles memory allocation
itself. If that's not what you want, you *probably* don't want to be
using Perl. It's okay, there are other good languages. I will sometimes
use C for precisely this reason.
> What if I don't want my program to commit suicide just because a brk()
> failed somewhere deep in the guts of the interpreter?
Code your program to use less memory. There are some hacks you can work
around, but they're really only for extreme cases and fatal emergencies.
> perl actively discourages proper handling of memory shortages. That is
> the opposite of "robust". A robust program must be able to keep going
> after any resource alllocation failure, including memory.
You can have a programming language that continues running under low
memory conditions, or you can have a programming language that takes care
of all memory allocation issues for you so that you don't have to worry
about buffer overflows, freeing things, and all the nit-picky overhead.
Pick one. It's damn hard to have both, and probably impossible in the
general case.
> C allows these things.
C allows a lot of low-level control that Perl doesn't. This is
intentional. C is portable assembly language; Perl is a high-level
language.
--
#!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker
$^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD,
00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
------------------------------
Date: Sun, 16 May 1999 08:05:52 GMT
From: armchair@my-dejanews.com
Subject: Re: Perl "constructors"
Message-Id: <7hlu8v$bl9$1@nnrp1.deja.com>
In article <926819373.57195@thrush.omix.com>,
zenin@bawdycaste.org wrote:
> armchair@my-dejanews.com wrote:
>
> : Actualy, I haven't left C++. Would I be correct in surmising that
the
> : slogan of this newsgroup is not "everybody join in".
>
> No, but we do have a minimum brain cell count.
The other fellows only mentioned brain size. I am sure glad you
mentioned cell count, as my size is small, but so are my cells, so no
problemo.
>
> >snip<
> : Well, hashes are variable in size and you appear to feel they
involve no
> : meaningful performance degradation (but you also appear to hold
bias) but
> : one does need to depend on the fact that variables have been added,
or use
> : exists() which is not necessary with structs.
>
> It's not necessary in Perl either.
That statement is meaningless without a code example of a subroutine tha
t receives a hash and expects a certain key, which isn't present, and
handles it without exists().
>
> : And as we and others have discussed, it does need an entries()
function
> : for clarity and performance.
>
> Maybe my news feed is broken (not likely), but I have yet to see
a
> single reply that agrees with you on this. You'll use keys()
and
> like it.
Maybe agreement isn't the right word, but I certainly have gotten lots
of positive feedback.
>
> : And structs, like C++ differing variable types allow the catching of
> : syntax errors at compile time. And that is not a trivial benefit.
>
> See fields.pm. You also don't seem to know what the word
"syntax"
> means.
Perhaps not, but I am familiar with the term supercilious.
>
> >snip<
> : The "one reference per object" is only a minor complaint.
>
> Who says you can only have one reference per object?
>
> my $self = {};
> $self->{ref1} = { foo => 10, bar => 20 };
> $self->{ref2} = { this => 10, that => 20 };
>
That is one reference per object. $self. I am aware that you can have
that reference point to a data structure, which in turn can hold
references to other data structures. I have in fact, despite my small
brain (with lots of tiny cells), even created objects of that fashion.
> : My major complaint with the Perl language (and I felt this way about
Basic
> : and dBase III and Rexx and other loosely typed interpreted languages
as
> : well - so don't take it so personally - is that one variable can at
one
> : moment hold a number, and another moment hold a string (not to
mention
> : references).
>
> That's a feature.
I don't agree, and would like to hear someone give examples of what
that buys you.
And regarding a scalar holding a number, looking the same as a scalar
that holds a reference, which looks the same as a scalar that holds a
string, I give you this quotation from the inaugural issue of the Perl
Journal - "One of the ideas I keep stressing in the design of Perl is
that things that ARE different should LOOK different."
>
> --
> -Zenin (zenin@archive.rhps.org) Caffeine...for the mind.
> Pizza......for the body.
> Sushi......for the soul.
> -- User Friendly
>
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
Date: 16 May 1999 01:15:44 -0700
From: Russ Allbery <rra@stanford.edu>
Subject: Re: Perl "constructors"
Message-Id: <ylu2td1lcf.fsf@windlord.stanford.edu>
armchair <armchair@my-dejanews.com> writes:
> Are you sure the above is correct?
> I got a Perl error with (possibly from use strict;)
> print @{$record{array}}
> but
> print @{$record->{array}}
> does run through (see code below).
> But I am confused. There are two references to dereference, one is a
> reference to a hash - $record; Then there is a reference to an array
> stored in the hash with key "array".
Yes, you're confused. There's only one reference in my example. Both are
valid Perl code, depending on what data structures you're using.
$record{array} is the value of the 'array' key in the *hash* %record.
$record->{array} is the value of the 'array' key in the hash *pointed* to
by the *scalar* $record.
> So I guess -> dereferences the hash reference and returns a reference to
> the array, which is then dereferenced by the "code block" {} returning
> an array??
Right.
> Which leaves the @ symbol. Why is that necessary?
Because you're dereferencing an array. It's necessary for the same reason
that the @ is needed on @array when you're talking about the array. It
distinguishes it from $array, the scalar.
> Didn't the code block dereference an array reference into the actual
> array?
Think of @{ ... } as a single construct, not two constructs @ and { ... }.
The @ tells Perl that it's evaluating something to get an array ref, and
then looking at the actual array.
You can also do things like %{ ... } to talk about a hash that you get
from a complicated expression, or ${ ... } for a scalar.
> *****************************************
> #!/usr/local/bin/perl -w
> use strict;
> use diagnostics;
> my $record = {};
> my @array = (1,2,3);
> $record->{array} = \@array;
> print @{$record-> {array}};
> **************************************
My syntax will work if you use:
my %record;
$record{array} = \@array;
instead rather than using an anonymous hash.
--
#!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker
$^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD,
00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
------------------------------
Date: 16 May 1999 01:28:14 -0700
From: Russ Allbery <rra@stanford.edu>
Subject: Re: Perl "constructors"
Message-Id: <ylogjl1krl.fsf@windlord.stanford.edu>
armchair <armchair@my-dejanews.com> writes:
> So, that gives us:
> if ( success )
> { return bless a } else { die "failed in constructor because of zz"; }
> That solves the problem of not checking a return code, but not all
> constructor failure would be fatal errors would they? What if the
> operation performed was just one of several the user could attempt in
> that session and they were quite willing to wait until later, or
> complete their other tasks and just leave that item incomplete?
Then the user has to catch the exception and retry later. The programmer
does have to deal with that overhead explicitly.
> But a constructor can fail for having invalid parameters passed. Like a
> filename that doesn't exist, or for which the user doesn't have read
> permission. Or a number that is out of range or otherwise invalid for
> the logic to be performed on it.
Some of that stuff ends up not being a problem in Perl, but yes, those are
good examples of failing constructors. A common way of handling this is
to call die and throw an exception. There are a few other ways of
handling it, though. Another is to return undef and set $@ directly; that
way, you don't have to wrap the call in eval { }, and programs that don't
care about the precise error can just go off the truth value of the
constructor.
A third way, for "low level" objects like IO::File or the like, is to
return undef and set $!. This only works if there's some one-to-one
correspondence between the constructor and a system call.
> The type of failure I was talking about is like the example given:
> someone has a Connect() constructor and it is depending on things
> outside the control of your program. e.g. - a database is down, a server
> program is down, a remote host is down. In those cases it is nice if a
> program can respond gracefully to an unavoidable event that is bound to
> occur occasionally with more than just "didn't work, I'm outta here".
Right, throwing an exception is probably what you want there.
> A constructor will never fail to create a reference to itself in Perl,
> for sure. I am saying that if you throw other code into a constructor,
> code that depends on things happening outside of a program, or depends
> that things have already taken place in the current program, you can
> have failures.
Agreed.
--
#!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker
$^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD,
00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
------------------------------
Date: Sun, 16 May 1999 08:18:35 GMT
From: armchair@my-dejanews.com
Subject: Re: Perl "constructors"
Message-Id: <7hlv0p$c80$1@nnrp1.deja.com>
In article <slrn7js9kn.d4q.sholden@pgrad.cs.usyd.edu.au>,
sholden@cs.usyd.edu.au wrote:
> >
> >Actualy, I haven't left C++. Would I be correct in surmising that the
> >slogan of this newsgroup is not "everybody join in".
>
> Of course it's not. It's about perl, so first one should learn some
perl
> so they actually have a vague clue what is going on...
Have you gurus ever thought about a comp.lang.perl.beginner newsgroup,
or is it just a case of "me thinks thou doest protest too much".
>
> >
> >>
> >
> >Well, hashes are variable in size and you appear to feel they involve
no
> >meaningful performance degradation (but you also appear to hold bias)
> >but one does need to depend on the fact that variables have been
added,
> >or use exists() which is not necessary with structs. And as we and
> >others have discussed, it does need an entries() function for clarity
> >and performance. And structs, like C++ differing variable types allow
> >the catching of syntax errors at compile time. And that is not a
trivial
> >benefit.
>
> The performance degredation of a hash compared to a struct is
> negligible compared with the performance degradation of using perl
> over C.
>
> On uses a hash _exactly_ the same way one uses a struct if that is
what
> one wants. The advantage is that when you create one instead of all
your
> values being random crap as in C, they are all set to undef in perl.
> If the hash is being used as a struct, then you have no need to check
it's
> size, you know what's in it. It contains the fields you say it does.
>
> Perl allows the catching of such errors at run time which is just as
good,
> since perl runtime errors are much clearer then 'Bus error - core
dumped'.
I ask you to write a subroutine for me. It will receive a hash, one of
who's keys is "input filename", and read the first line of the file and
fill in the key "first line" with the first line of the file. You are
wary that I might pass the hash correctly, but may have not filled in
any key value of "input filename". What does your code look like
assuming that I have asked you to pass back 0 on success, 1 on file open
error and 2 for bad parameter list? In other words, how do you get
around using exists()?
> >
> >And I am trying to learn Perl, but have run into some mixed opinions
on
> >whether or not I am doing the right thing...
>
> No your not. Don't use perl. You don't like loosely typed languages.
Perl
> is loosley typed. So use something that is strongly typed. Pretty
obvious
> really.
But you keep steering me to Python, and that is loosely typed as well.
And those are the two primary CGI languages, no? So until I reach
financial independence, I need to know about what is relevant, whether I
like it or not.
>
> --
> Sam
>
> I explicitly give people the freedom not to use Perl, just as God
gives
> people the freedom to go to the devil if they so choose.
> --Larry Wall
>
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
Date: Sun, 16 May 1999 08:24:01 GMT
From: armchair@my-dejanews.com
Subject: Re: Perl "constructors"
Message-Id: <7hlvb0$ca2$1@nnrp1.deja.com>
In article <7hka3t$16n8$1@nntp6.u.washington.edu>,
snow@biostat.washington.edu (Gregory Snow) wrote:
> In article <7hjhv6$r17$1@nnrp1.deja.com>, <armchair@my-dejanews.com>
wrote:
>
> [snip]
>
> >Hmmm, lacking knowledge, or showing poor judgement regarding program
> >speed. That's an easy one - I don't know Perl. How does access of
hashes
> >compare to arrays performance-wise?? And does the size of the hash
key
> >string affect it?
>
> [snip]
>
> >Actualy, I haven't left C++. Would I be correct in surmising that the
> >slogan of this newsgroup is not "everybody join in".
>
> I think the slogan is more like "Do your homework"
>
> If you had started out by asking why or how, instead of saying what
> was wrong without trying to understand why many consider it right, you
> would have received a much more positive response.
Suggesting changes to Perl gets a negative response. But as you imply
with your slogan, asking why or how also gets a negative response if the
regulars feel it is not above a certain threshold of Perl knowledge.
>
> --
>
------------------------------------------------------------------------
-------
> Gregory L. Snow | MATZ'S RULE REGARDING MEDICATIONS:
> (Greg) | A drug is that substance which, when
injected
> snow@biostat.washington.edu | into a rat, will produce a scientific
report.
>
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
Date: 16 May 1999 01:36:42 -0700
From: Russ Allbery <rra@stanford.edu>
Subject: Re: Perl "constructors"
Message-Id: <yllnep1kdh.fsf@windlord.stanford.edu>
armchair <armchair@my-dejanews.com> writes:
> I ask you to write a subroutine for me. It will receive a hash, one of
> who's keys is "input filename", and read the first line of the file and
> fill in the key "first line" with the first line of the file. You are
> wary that I might pass the hash correctly, but may have not filled in
> any key value of "input filename". What does your code look like
> assuming that I have asked you to pass back 0 on success, 1 on file open
> error and 2 for bad parameter list? In other words, how do you get
> around using exists()?
Er, why on earth would you write it that way in Perl?
sub first_line {
my $filename = shift;
open (FILE, $filename) or return undef;
return <FILE>;
}
print first_line ('filename');
That will return the first line of the given file, undef on failure to
open the file, and the empty string if the file is empty. You'll find
that all of the possible cases are well-defined. If you want to know why
the file couldn't be opened, the reason will be in $!.
One of the ways that Perl gets around having to have return codes in
nearly every case is by having the value "undef" for indicating
exceptional conditions like this. The concept of a return code is very
C/C++ and usually isn't needed in Perl.
--
#!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker
$^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD,
00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
------------------------------
Date: Sun, 16 May 1999 08:49:29 GMT
From: armchair@my-dejanews.com
Subject: Re: Perl "constructors"
Message-Id: <7hm0qp$d91$1@nnrp1.deja.com>
In article <cWt%2.139$fx5.345@news.rdc1.sfba.home.com>,
"Stephen Warren" <swarren@www.wwwdotorg.org> wrote:
> <armchair@my-dejanews.com> wrote in message
> > > Er. Of course one has an idea.
> > >
> > > my $new_object = MyClass->Connect() || die "Couldnt connect - ";
> >
> > And just what is happneing in your "constructor". If we to look at
the
> > last few lines, what, other than "bless $rSelf, $sClass;" would we
see?
> > Again, I will repeat myself - if you look at Perl discussions of
objects
> > they say a "constructor" returns a reference to the object. Are you
know
> > suggesting that constructors should also return scalar number and/or
> > strings in the case of errors?
>
> *NO* It returns undef (which is roughly equivalent to NULL in some
other
> languages). This evaluates to a false value on the LHS of the ||
operator
> and hence the RHS (die) is executed.
I will assume that open() also returns undef on error as I cannot do
the following when an invalid filename is given.
my $scalar = open(HANDLE,"my_file");
if ( $scalar > 0 )
{
... good
}
else
{
... error
}
The above generates a warning saying that a variable was used as if it
has already been defined. It was interpreted as "" or 0, but maybe it
was a mistake. To supress this warning assign an initial value to your
variables.
but I can do: if ( $scalar )
and get no warnings.
My question is, what does assigning undef to a variable do - cause it to
go away?? Does it undefine the variable, not giving it an undefined (or
in SQL terms NULL) value?
>
> > > But of course it is a prerequisite of the troll that they have no
> > > knowledge of the subject which they set upon.
> >
> > But of course it is a prerequisite of a bigot that when anyone dares
> > query their religiously held beliefs that they resort to ad hominem
> > attacks.
>
> Or a pre-requisite of a bigot who refuses to learn the basic concepts
and
> then argues against those who know much better. I assume that you do
know
> who TC is? And whilst I don't know of everyone else in this
> 'conversation', they all have said correct things...
Even Sam, who keeps advocating Python? And I haven't refused to learn
the basic concepts of Perl, I have bought 3 books on it, and have even
read most of two of them (one is awful thick and scary). But none of
them have animals on the cover, which is why I don't now who TC is,
other than someone who gets very upset if you question Perl syntax.
>
> --
> Stephen Warren, Snr Systems Engineer, Technology House, San Francisco
> mailto:swarren@techhouse.com http://www.techhouse.com/
> mailto:swarren@wwwdotorg.org http://www.wwwdotorg.org/
> MIME, S/MIME and HTML mail are acceptable
>
>
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
Date: Sun, 16 May 1999 09:28:41 GMT
From: pacman@defiant.cqc.com (Alan Curry)
Subject: Re: Perl "constructors"
Message-Id: <ddw%2.4584$M3.113087@news7.ispnews.com>
In article <ylwvy91lny.fsf@windlord.stanford.edu>,
Russ Allbery <rra@stanford.edu> wrote:
>Alan Curry <pacman@defiant.cqc.com> writes:
>
>> So the fact that perl completely ignores memory allocation issues is a
>> _feature_?
>
>Yes.
[...]
>You can have a programming language that continues running under low
>memory conditions, or you can have a programming language that takes care
>of all memory allocation issues for you so that you don't have to worry
>about buffer overflows, freeing things, and all the nit-picky overhead.
>Pick one. It's damn hard to have both, and probably impossible in the
>general case.
If it is really that difficult to support a choice of memory allocation
policies (which I doubt), then why must the _unsafe_ policy be the Chosen
One? Why not have perl always sleep-and-retry after a brk failure at any
level? A machine that's running low on memory will be receiving administrator
attention eventually. Wouldn't it be nice if after the runaway emacs is
killed, the important daemons are still there, waiting patiently for the
opportunity to resume operation right where they left off?
Perl's current behavior turns a simple temporary error into an unnecessarily
fatal one.
If it's possible to implement sleep-and-retry with $^M, please tell me how. The
real $^M documentation is nonexistent as far as I can tell. (perlvar refers
to INSTALL, but there's nothing in there)
--
Alan Curry |Declaration of | _../\. ./\.._ ____. ____.
pacman@cqc.com|bigotries (should| [ | | ] / _> / _>
--------------+save some time): | \__/ \__/ \___: \___:
Linux,vim,trn,GPL,zsh,qmail,^H | "Screw you guys, I'm going home" -- Cartman
------------------------------
Date: Sun, 16 May 1999 09:29:32 GMT
From: armchair@my-dejanews.com
Subject: Re: Perl "constructors"
Message-Id: <7hm35r$ekc$1@nnrp1.deja.com>
In article <ylhfpd4y4w.fsf@windlord.stanford.edu>,
Russ Allbery <rra@stanford.edu> wrote:
> armchair <armchair@my-dejanews.com> writes:
Your point about a solid suite of test cases being necessary to
completely checkout any large project is well taken. But as studies
show, the sooner that errors are caught, the cheaper and less negative
it is to the project. And,the C designers decided to move away from
allowing flexible and variable parameter passing, to enforcing strict
parameter prototyping. Since Perl has added optional prototyping as
well, I think that some top computer science people must feel that there
is an advantage to catching the fact that a subroutine is being called
incorrectly the first time it is compiled, rather than when it fails
test case #15 during checkout. But to really check at compile time you
have to have variable typing. I definitely need to checkout this
Field.pm.
>
> > Huh? C++ has a required syntax for accessing variables in data
> > structures that leaves no abiguity. struct mystruct { int b; }
> > mystruct zzz;
> > zzz.b = 10;
>
> For structs. Now what about private data members of an object,
accessed
> from inside a method of that object? In the middle of a long method,
it's
> often not at all obvious whether one is dealing with a variable local
to
> that method or a variable that's stored in the object itself.
>
> Perl makes this explicit.
To handle this, many C++ programmers are now using m_ as a prefix on the
names of member data. (e.g. m_numberOfItems) And as you mention below,
there is a this pointer, and that could always precede the variable name
as in this->items instead of items. In effect, the this pointer would
function like the reference to the object of Perl.
I am not clear on how Perl makes it any more explicit. If you are passed
references to your method, you will be dereferencing them in addition to
variables that you are dereferencing that your object reference is
pointing to. It would seem that the only thing that makes it clear is if
the programmer gives appropriately clear names to the references.
$ref1->{items} = $refb->{items}; is not clear what is taking place but
perfectly legal but
$input_parameter->{items} = $self->{items}; is clear through pgmer
variable naming
>
> > I guess what bothers me is that in C++ I can construct object member
> > data your Perl way, or my desired Perl way. C++ is so libertarian
about
> > object construction that it allows us to both do it different ways.
It
> > doesn't enforce an object data member style on either one of us the
way
> > Perl does.
>
> Er... I think you're not understanding the flexibility of Perl.
You're
> thinking of the blessed reference as a pointer to the object's data.
> That's not a good way to think of it, in my opinion. Instead, think
of
> that reference as equivalent to the "this" pointer in C++.
>
> C++ basically requires all your objects to be hashes, in the sense
that
> their data elements are all named values of some sort and you access
them
> by name. That's the normal way of doing it in Perl as well, but Perl
also
> allows blessed arrays or even blessed file handles and other odd
things,
> for those times when you want to do something very different.
C++ has pointers, which are identical to Perl references - they store
the address of other variables, and you dereference them to get at the
data that is being referred to (or pointed to), which themselves can be
complex data structures. You could look inside a C++ class and see only
one member variable MyMapPointer *m_pMap;
or it could be a pointer to an array MyArray *m_pArray;
even though the class is actually representing all the organizations and
employees of a company.
In any event, it is not a real concern, as was asked and answered before
- the Perl object way has not caused me to hit a wall. I have made
several classes/packages/modules and have had both a reference to an
array and a reference to a hash in a class.
>
> --
> #!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker
> $^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD
gD,
> 00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.),
01,pnn,y{
> rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/
#y,d,s,(\$.),$1,gee,print
>
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
Date: 16 May 1999 02:41:10 -0700
From: Russ Allbery <rra@stanford.edu>
Subject: Re: Perl "constructors"
Message-Id: <yld8011he1.fsf@windlord.stanford.edu>
Alan Curry <pacman@defiant.cqc.com> writes:
> If it is really that difficult to support a choice of memory allocation
> policies (which I doubt), then why must the _unsafe_ policy be the
> Chosen One? Why not have perl always sleep-and-retry after a brk failure
> at any level?
Um, you'll find that the *vast* majority of all programs immediately exit
on a memory allocation failure. Probably 99% of them. That's usually
what you want to do. Long running processes that should keep running in
the face of any failure condition are the *very uncommon* case.
> Wouldn't it be nice if after the runaway emacs is killed, the important
> daemons are still there, waiting patiently for the opportunity to resume
> operation right where they left off?
Generally, when writing a long-running daemon, you want to allocate all
the memory you're going to be using up-front. In fact, unless your daemon
grows without bound, you're likely to do that whether you want to or not
since free() doesn't return memory to the operating system under most
conditions.
> If it's possible to implement sleep-and-retry with $^M, please tell me
> how. The real $^M documentation is nonexistent as far as I can
> tell. (perlvar refers to INSTALL, but there's nothing in there)
Ilya would probably be the expert on that, but I don't think there's a way
of doing that with that mechanism.
--
#!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker
$^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD,
00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
------------------------------
Date: Sun, 16 May 1999 10:19:40 +0100
From: "Sandwell" <JK@sandwell98.free-online.co.uk>
Subject: Please Help.???
Message-Id: <Oew%2.4882$%x.4261@wards>
HI,
This question may of been posted here before, but I have just begin here for
a week. I am writing a mult-user guestbook in perl.
When a user clicks on the link to add an entry (from a standard HTML page,
using <A HREF>) how do you get a perl script to read though the page, where
the link came from and look for a tag called <!- username = me -!> and then
assign the input after the "=" to $username.
So, I could them use -
print "You are adding to the guestbook of $username ";
Any Idea, I don't want to use a perl module.
Graeme@sandwell98.free-online.co.uk
------------------------------
Date: 16 May 1999 02:43:47 -0700
From: Russ Allbery <rra@stanford.edu>
Subject: Re: Please Help.???
Message-Id: <ylaev51h9o.fsf@windlord.stanford.edu>
Sandwell <JK@sandwell98.free-online.co.uk> writes:
> When a user clicks on the link to add an entry (from a standard HTML
> page, using <A HREF>) how do you get a perl script to read though the
> page, where the link came from and look for a tag called <!- username =
> me -!> and then assign the input after the "=" to $username.
Is the page they came from dynamically generated? If so, you can't. You
need to use forms with hidden fields, cookies, or some other mechanism to
pass the state along to your Perl script.
BTW, this is a CGI programming question, not a Perl question. You'd be
much better off asking it in comp.infosystems.www.authoring.cgi.
--
#!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker
$^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD,
00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
------------------------------
Date: Sun, 16 May 1999 08:15:36 GMT
From: rcastro@nospam.jps.net (rcastro)
Subject: problem w/perl cgi script & background image
Message-Id: <373eebc1@news1.jps.net>
Hi,
I'm having problems with one of my Perl CGI scripts.
I want the script to generate a web page that uses
a background image (a .gif file).
To illustrate what happens, go to:
http://www.jps.net/rcastro/test.html
This shows how the page is SUPPOSED to look.
Now go to:
http://www2.jps.net/cgi-bin/cgiwrap/rcastro/test.cgi
This is the same page, except the HTML is generated
by my CGI script, and I can't get the background to show
up. Any ideas???? The source code is the same, the gif
is the same, the file permissions are the same - the only
difference is that one page is static HTML and the other
is generated by a Perl script. The one generated by
the Perl script won't display the background image properly.
If anybody knows what I am doing wrong, please email me
at rcastro@jps.net
Thanks,
Randy
Here is my Perl script:
=========================
#!/usr/local/bin/perl
use CGI;
$ans = new CGI;
print $ans->header;
print $ans->start_html(-BACKGROUND=>'background.gif');
print ("<center>\n");
print ("<h2>Can you see the pretty background?</h2>\n");
print ("</center>");
print $ans->end_html;
------------------------------
Date: Sun, 16 May 1999 11:46:25 +0200
From: Isaac Keslassy <amig@csi.com>
Subject: Re: Saving regularly a web page
Message-Id: <373E93F1.559F24C4@csi.com>
Hi,
Thanks for your suggestion.
I am sorry, I think I have not explained clearly what I wanted. I know
getprint, but I don't know how to launch it automatically each hour -
for instance, if I want to save a page of news (Reuters, Wired, etc.) on
my server each hour, but with the possibility of sleeping and going to
holidays sometimes ...
So perhaps my question is: how can I launch a perl program regularly on
my Windows system ? Perhaps it's not the appropriate newsgroup...
Thanks again,
Isaac
Jonathan Stowe wrote:
>
> On Sat, 15 May 1999 22:43:34 +0200 Isaac Keslassy wrote:
> > Hi,
> >
> > I want to save a web page regularly and automatically on my server (for
> > instance, to save http://www.perl.com each 30 minutes), in order to
> > avoid waiting the page when I want it (i'll be able to make
> > http://localhost/perl.html and i'll get it).
> >
>
> perl -MLWP::Simple -e'getprint("http://ww.perl.com")'
>
> /J\
> --
> Jonathan Stowe <jns@gellyfish.com>
> Some of your questions answered:
> <URL:http://www.btinternet.com/~gellyfish/resources/wwwfaq.htm>
> Hastings: <URL:http://www.newhoo.com/Regional/UK/England/East_Sussex/Hastings>
------------------------------
Date: Sun, 16 May 1999 11:53:07 +0200
From: Isaac Keslassy <amig@csi.com>
Subject: Re: Saving regularly a web page
Message-Id: <373E9583.9956C6B5@csi.com>
Hi,
Thanks for your suggestion, but it wasn't exactly what I wanted.
> > I want to save a web page regularly and automatically on my server
> > (for instance, to save http://www.perl.com each 30 minutes), in
> > order to avoid waiting the page when I want it (i'll be able to make
> > http://localhost/perl.html and i'll get it).
>
> The word is "caching", and you can search on the engine of your choice
> for caching services. There's no point in your doing this on your own,
> unless you really need to, as plenty of people already are.
Yes, I really need to have immediately those pages when I ask them, so
using the cache of others won't really help me... I need to cache the
pages on my own server.
By the way, what's the difference between mirroring and caching ?
> If you feel that you really need to look into wget (a stand-alone
> utility) or LWP (a perl module).
In fact, I know them both. My problem is to launch them regularly (eg
each hour) on my windows system, without manual intervention. Is it
possible to do that with perl ?
Thanks again,
Isaac
------------------------------
Date: Sun, 16 May 1999 08:51:00 GMT
From: ran@netgate.net (Ran)
Subject: Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Design
Message-Id: <926844660.176.47@news.remarQ.com>
In <7h9n93$3lj$1@ffx2nh3.news.uu.net>, "Matt Kruse" <mkruse@rens.com> writes:
>There has to be some expectation that people will keep up with technology.
No, there has to be some expectation that people will *not* keep up
with technology. Especially when the "technology" in question is
nothing but the latest cutesy doo-dad from Redmond that has nothing to
do with the basic function of the net: information interchange among
diverse peoples and platforms.
The entire point of setting up standards like NNTP, HTTP, and even the
design of Perl, is to enable lots of different people, who are at
different points along the *multiple* "technology curves" that exist in
the world today, to interact, share information, and even share code.
>People who write games don't expect to support 486's anymore, even though
>there are plenty of people with them.
Games are a luxury. Commerce and communications are necessities.
>Well, people who create web sites
>these days can't be expected to support Netscape 2.0 with full
>functionality either. People with out-of-date tools can only *expect* to
>see things in a limited fashion.
People with up-to-date tools that support the standards designed for
cross-platform interoperability should not.
Example: I was looking for work recently. One of the websites I used
to search for job listings was constantly overrun with repostings of old
ads (literally over 80% of what appeared in response to a request for
"new" listings were actually reposts of old unfilled positions). Because
the website was set up to properly support text-only access, I was able
to whip up a user agent that screened out the reposts, saving me many
hours of tedious manual sifting. And because the agent is written in
Perl, I was able to share it with someone else facing the same problem,
who was running a completely different operating system.
The same technique can be used to create text-to-speech or
text-to-braille agents for the blind or deaf-blind, translation proxies
that will enable people who know only Swahili to do business with
American firms where everyone knows only Engish, and intelligent search
agents that can *start* from Altavista or Yahoo, and screen the results
to save their owners' time.
But only if web designers stick to the principle that's been part of
*nix (and, later, Perl) from initial conception: the storing of
information in a form that allows users to bring the maximum possible
number of tools possible to bear when they need to sort, scan,
summarize, or otherwise make use of it.
If they don't, then their sites become just another video game that
runs under Windoze.
Ran
------------------------------
Date: 16 May 1999 01:22:19 -0700
From: Russ Allbery <rra@stanford.edu>
Subject: Re: TROLL ALERT (Re: Perl "constructors")
Message-Id: <ylr9oh1l1g.fsf@windlord.stanford.edu>
armchair <armchair@my-dejanews.com> writes:
> Russ Allbery <rra@stanford.edu> wrote:
>> To me, a constructor is a function that I call to get a new object of a
>> given type. This isn't how C++ uses the term, but it's the *intuitive*
>> definition of the term for me. C++ therefore has all sorts of
>> constructors that aren't named "new()"; anything that creates a new
>> object and returns it is a constructor.
>> If you really want to use C++'s definition for constructor, Perl *does*
>> only have one constructor. bless().
> In C++ the constructor (member function that creates an object of that
> class) has the exact same name as the class of the object it is
> constructing. Their are no exceptions. [...]
> "new" is a reserved word that is used to dynamically allocate memory.
Yes, yes, I know, I'm glossing over the details. new is the normal way of
calling a constructor in C++; I know that the method isn't actually named
that, and that you can also just allocate an object off the stack and the
constructor gets called that way.
The point still stands, however. Perl objects are fundamentally very
different things than C++ objects; they don't inherently do any
initialization when they're created, and anyone can create an object
called anything they want. Perl gives you a lot more control over the
entire process. You can do things the C++ way, but you can also do them a
lot of other interesting ways.
> A member function may create an instance of some other class, and return
> it, but that would not be called a "constructor" just because it is
> "instantiating" or creating an object of another class.
It's logically a constructor, however, which is my point. It constructs
an object. The C++ distinction is one of language semantics, not actual
usage in a program.
--
#!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker
$^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD,
00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
------------------------------
Date: 12 Dec 98 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Special: Digest Administrivia (Last modified: 12 Dec 98)
Message-Id: <null>
Administrivia:
Well, after 6 months, here's the answer to the quiz: what do we do about
comp.lang.perl.moderated. Answer: nothing.
]From: Russ Allbery <rra@stanford.edu>
]Date: 21 Sep 1998 19:53:43 -0700
]Subject: comp.lang.perl.moderated available via e-mail
]
]It is possible to subscribe to comp.lang.perl.moderated as a mailing list.
]To do so, send mail to majordomo@eyrie.org with "subscribe clpm" in the
]body. Majordomo will then send you instructions on how to confirm your
]subscription. This is provided as a general service for those people who
]cannot receive the newsgroup for whatever reason or who just prefer to
]receive messages via e-mail.
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.
To submit articles to comp.lang.perl.misc (and this Digest), send your
article to perl-users@ruby.oce.orst.edu.
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.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
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 V8 Issue 5682
**************************************
