[12081] in Perl-Users-Digest
Perl-Users Digest, Issue: 5681 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun May 16 04:07:22 1999
Date: Sun, 16 May 99 01:01:21 -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: 5681
Today's topics:
Re: Perl "constructors" (Alan Curry)
Re: Perl "constructors" (Lee)
Re: Perl "constructors" <swarren@www.wwwdotorg.org>
Re: Perl "constructors" <swarren@www.wwwdotorg.org>
Re: Perl "constructors" <swarren@www.wwwdotorg.org>
Re: Perl "constructors" armchair@my-dejanews.com
Re: Perl "constructors" <swarren@www.wwwdotorg.org>
Re: Perl "constructors" armchair@my-dejanews.com
Re: Perl "constructors" (Andrew Johnson)
Re: Perl "constructors" (Sam Holden)
Re: Perl "constructors" (Charles R. Thompson)
Re: Perl "constructors" armchair@my-dejanews.com
Re: PERLFUNC: keys - retrieve list of indices from a ha (Larry Rosler)
Re: perltootc - OO Tutorial for Class Data in Perl <swarren@www.wwwdotorg.org>
Re: TROLL ALERT (Re: Perl "constructors") armchair@my-dejanews.com
Special: Digest Administrivia (Last modified: 12 Dec 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 16 May 1999 06:12:09 GMT
From: pacman@defiant.cqc.com (Alan Curry)
Subject: Re: Perl "constructors"
Message-Id: <Zkt%2.7423$LP2.144431@news6.ispnews.com>
In article <ylyaip4zsm.fsf@windlord.stanford.edu>,
Russ Allbery <rra@stanford.edu> wrote:
>
>It turns out that most of the reason why constructors fail in C++ is due
>to memory allocation problems, and in Perl you don't have to worry about
>that. So it's actually fairly rare for constructors to fail in Perl, and
>you usually don't have to worry about it. If you do, the constructor can
>document that it throws exceptions, and you can catch them if you want.
So the fact that perl completely ignores memory allocation issues is a
_feature_?
What if I don't want my program to commit suicide just because a brk() failed
somewhere deep in the guts of the interpreter?
perlvar says:
$^M By default, running out of memory it is not
trappable. However, if compiled for this, Perl
may use the contents of $^M as an emergency pool
after die()ing with this message. Suppose that
your Perl were compiled with -DPERL_EMERGENCY_SBRK
and used Perl's malloc. Then
$^M = 'a' x (1<<16);
would allocate a 64K buffer for use when in
emergency. See the INSTALL file for information
on how to enable this option. As a disincentive
to casual use of this advanced feature, there is
no the English manpage long name for this
variable.
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. The reasonable thing to do
depends on what kind of program you're writing. In an interactive program,
it's usually safe to print an error message and exit, and let the user retry
later. A server type program, though, should not do that. It should keep
going. Maybe it will return a "temporary error" code to the client whose
request led to the malloc() failure. Maybe it will just wait a couple seconds
and then retry.
C allows these things. Perl locks you in to the "If malloc() fails, you die"
policy which means it's basically only good for progams that will have
someone watching over them as they run to make sure they do what they're
supposed to do.
--
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 01:26:46 -0500
From: rlb@intrinsix.ca (Lee)
Subject: Re: Perl "constructors"
Message-Id: <B363CF569668B1D315@0.0.0.0>
In article <373d5fd9@cs.colorado.edu>,
Tom Christiansen <tchrist@mox.perl.com> wrote:
>I've had enough.
Does that mean you'll stop feeding this exchange of insults and inanities?
Promise?
Lee
------------------------------
Date: Sun, 16 May 1999 06:51:52 GMT
From: "Stephen Warren" <swarren@www.wwwdotorg.org>
Subject: Re: Perl "constructors"
Message-Id: <cWt%2.139$fx5.345@news.rdc1.sfba.home.com>
<armchair@my-dejanews.com> wrote in message
news:7hlkoj$4vk$1@nnrp1.deja.com...
> In article <7hk10r$220$1@gellyfish.btinternet.com>,
> Jonathan Stowe <gellyfish@gellyfish.com> wrote:
> > On Sat, 15 May 1999 13:16:43 GMT armchair@my-dejanews.com wrote:
> > > In article <373d5fd9@cs.colorado.edu>,
> > > tchrist@mox.perl.com (Tom Christiansen) wrote:
> > >> In comp.lang.perl.misc, armchair@my-dejanews.com writes:
> > >> :You cannot connect() with a
> > >> :constructor and get a status code back from the connect()
> > >> :you get a
> > >> :reference to the object just created whether your
> > >> :connection has been
> > >> :successful or not. This problem exists in C++ as well.
> > >>
> > >> You're wrong. That's not the way it works in Perl.
> > >
> > > Oh, and how does it work in Perl.
> > > I have only seen examples where a Perl constructor returns a
> > > reference to a blessed variable which is a reference.
> > > Hence the syntax
> > >
> > > my $new_object = MyClass->Connect();
> > >
> > > if Connect() (your constructor) fails, we end up with a
> > > reference to a object that has not connected. With no idea that
> > > it failed at this point.
> >
> > 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.
> > 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...
--
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
------------------------------
Date: Sun, 16 May 1999 06:54:29 GMT
From: "Stephen Warren" <swarren@www.wwwdotorg.org>
Subject: Re: Perl "constructors"
Message-Id: <FYt%2.140$fx5.352@news.rdc1.sfba.home.com>
<armchair@my-dejanews.com> wrote in message
news:7hlkr4$4vt$1@nnrp1.deja.com...
> In article <f9ljh7.gp4.ln@magna.metronet.com>,
> tadmc@metronet.com (Tad McClellan) wrote:
> > armchair@my-dejanews.com wrote:
> > : In article <7uc%2.10345$L4.363390@news2.rdc1.on.home.com>,
> > : andrew-johnson@home.com wrote:
> >
> > : > What makes you think that is what perl is doing?
> >
> > : Because the book I have - "Perl From the Ground Up" in it's built-in
> > : function reference says that keys "returns all the keys for the Hash
> > : named". It does not mention "scalar context" as some right honorable
> > : fellow was nice enough to point out that the perlfunc does inside of
> > : parenthese after stating the above regarding returning all the keys.
> >
> > Problems with a book are problems with the book, not with Perl.
> >
> > If you have problems with a book, contact someone connected
> > with producing the book.
> >
> > The only reference that matters are the docs that come with perl.
> >
> > If you find a problem there, then mention it here.
> >
> > If you find a problem elsewhere then mention it elsewhere.
>
> I think you need a hobby Tad.
He had one - helping out people in c.l.p.m who had questions about Perl
and were willing to listen to the free advice that was given out:-)
You cannot possibly believe that just because a book exists and its topic
is computing then everything it says is complete and correct? Even from
typos or editing mistakes? You obviously never typed in 1000-line listings
of BASIC programs from computer magazines!
--
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
------------------------------
Date: Sun, 16 May 1999 06:56:28 GMT
From: "Stephen Warren" <swarren@www.wwwdotorg.org>
Subject: Re: Perl "constructors"
Message-Id: <w_t%2.141$fx5.427@news.rdc1.sfba.home.com>
<armchair@my-dejanews.com> wrote in message
news:7hlktt$58j$1@nnrp1.deja.com...
> In article <slrn7js8rb.d4q.sholden@pgrad.cs.usyd.edu.au>,
> sholden@cs.usyd.edu.au wrote:
> > On Sat, 15 May 1999 12:42:58 GMT, armchair@my-dejanews.com wrote:
> > >
> > >Because the book I have - "Perl From the Ground Up" in it's built-in
> > >function reference says that keys "returns all the keys for the Hash
> > >named". It does not mention "scalar context" as some right honorable
> > >fellow was nice enough to point out that the perlfunc does inside of
> > >parenthese after stating the above regarding returning all the keys.
> >
> > So the book is wrong. Throw it out and buy 'Programming Python'.
>
> I've got it! I was all pumped to learn Python until I saw that it had
> the same thing I didn't like about Perl - a variable can hold either a
> string or a number at any time.
IIRC... This'll blow your mind: In Perl (don't know about Python), a
variable can hold a string and a numeric value at the *same* time...
Of course, the string would just be a textual representation of the number
stored, but...
--
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
------------------------------
Date: Sun, 16 May 1999 06:45:40 GMT
From: armchair@my-dejanews.com
Subject: Re: Perl "constructors"
Message-Id: <7hlpik$7r9$1@nnrp1.deja.com>
In article <ylpv414z0p.fsf@windlord.stanford.edu>,
Russ Allbery <rra@stanford.edu> wrote:
> armchair <armchair@my-dejanews.com> writes:
>
> What, you mean something like @{$record{array}}? It's kind of ugly
and
> not one of my favorite parts of Perl, although dereferencing a
reference
> is a simplification of what the outer {}s are doing. They're actually
> just a code block, like they are in a lot of other places in Perl.
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". 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?? Which leaves
the @ symbol. Why is that necessary? Didn't the code block dereference
an array reference into the actual array?
*****************************************
#!/usr/local/bin/perl -w
use strict;
use diagnostics;
my $record = {};
my @array = (1,2,3);
$record->{array} = \@array;
print @{$record-> {array}};
**************************************
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
Date: Sun, 16 May 1999 07:03:37 GMT
From: "Stephen Warren" <swarren@www.wwwdotorg.org>
Subject: Re: Perl "constructors"
Message-Id: <d5u%2.143$fx5.337@news.rdc1.sfba.home.com>
Alan Curry <pacman@defiant.cqc.com> wrote in message
news:Zkt%2.7423$LP2.144431@news6.ispnews.com...
> In article <ylyaip4zsm.fsf@windlord.stanford.edu>,
> Russ Allbery <rra@stanford.edu> wrote:
> >
> >It turns out that most of the reason why constructors fail in C++ is
due
> >to memory allocation problems, and in Perl you don't have to worry
about
> >that. So it's actually fairly rare for constructors to fail in Perl,
and
> >you usually don't have to worry about it. If you do, the constructor
can
> >document that it throws exceptions, and you can catch them if you want.
>
> So the fact that perl completely ignores memory allocation issues is a
> _feature_?
>
> What if I don't want my program to commit suicide just because a brk()
failed
> somewhere deep in the guts of the interpreter?
Java also pretty much does this... Whenever the JVM can't allocate any
required memory, it throws a java.lang.OutOfMemoryError. This being a
sub-class of java.lang.Error it's extremely unlikely to be caught, so it
will fall through to the JVM and it will exit.
An in Java, who knows when memory allocation might occur and fail - it
might be in the middle of an expression evaluation for all you know,
rather than just when the 'client' program creates an object. Of course, I
haven't investigated the Perl source code, so I have *no* idea if this is
true of Perl or not.
--
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
------------------------------
Date: Sun, 16 May 1999 07:21:51 GMT
From: armchair@my-dejanews.com
Subject: Re: Perl "constructors"
Message-Id: <7hlrmf$a6l$1@nnrp1.deja.com>
In article <slrn7js8nd.d4q.sholden@pgrad.cs.usyd.edu.au>,
sholden@cs.usyd.edu.au wrote:
> On Sat, 15 May 1999 09:40:32 GMT, armchair@my-dejanews.com wrote:
> >In article <ylzp366dm2.fsf@windlord.stanford.edu>,
> > Russ Allbery <rra@stanford.edu> wrote:
> >> armchair <armchair@my-dejanews.com> writes:
> >>
> >> > I can speak to this: connect() and prepare() should be member
> >functions
> >> > and not constructors as a member function can return a status
code
> >of
> >> > success or various error codes. A constructor cannot.
> >>
> >> Constructors certainly can return various error codes, as well as
> >success
> >> or failure.
> >
> >And what does your code look like?
> >
> >#constructor...
> >if ( success )
> >{ return bless a; } else { return 0; }
>
> No since return 0 is not how you return false in perl. But since you
can't
> be bothered looking up simple things you just make an incorrect
statement
> and then use it to show perl isn't how you like.
You are always on the defensive aren't you. I was trying to get the
other fellow to be more explicit and complete and you take it as an
attack on Perl and add another one of your ad hominem attacks, while
also not answering the question.
>
> >
> >#caller
> >
> >my $reference = myclass->new();
> >if ( $reference == 0 )
> >{
> > print "constructor failed\n";
> >}
> >
> >Correct?
>
> No more likely the simple :
> my $reference = myclass->new() || die "constructor failed";
Again we have the same problem as with the other fellow. What does the
code look like INSIDE THE CONSTRUCTOR.
>
> Perl does not restruct what a sub returns. It is not a strongly typed
> language. You are placing stupid restrictions on perl that don't
exist.
Again you are incredibly, astonishingly, unbelievably defensive. I ask a
question on how some fellow is writing his code (something he should
have stated, but is mostly just interested in ad hominem barks), and you
turn it into an an attack on Perl.
> If you want you could return anything you feel like on failure. If you
> want to return the string "I failed" then you can. If you want to
return
> the error code 42 then you can. If you want to return a reference to
an
> array of arrays of hashes to indicate error then you can.
What did you return in your above example???:
my $reference = myclass->new() || die "constructor failed";
>
> >>
> >> > In any event, you can't get around the fact that constructors
return
> >a
> >> > blessed reference. It's nice for functions that can fail, to
return
> >> > error codes. Or perhaps you are printing error messages and
exiting
> >your
> >> > program when your constructors fail??
> >>
> >> Have you heard of exceptions?
> >
> >In C++ and Java, but not in Perl. Does it have them, and if so which
> >perl HTML page section are they documented in?
>
> It's documented in perlfaq8 which you should have read before posting,
but
> you are obviously too stupid.
I think there are going to be quite a few people upset at you referring
to my desire to learn Perl as a demonstration of "obvious stupidity".
>
> It's also documented in perlfunc. It's mentioned in perltoc (how could
you
> not read that one?), and in perldelta, and perlfaq7, and I couldn't be
> bothered checking elsewhere...
Okay, I found a reference to exceptions.pl in perlfaq8, and references
to klugeing exception handling via eval(), die(). Thanks Sam.
>
> >> > I don't think it is too much to ask for a function, a complement
to
> >> > "exists" if you will, that tells how many items are in a hash.
> >>
> >> What, like $count = keys %hash?
> >
> >Very expensive, not intuitive. What is the hash has 2000 items.
Create
> >a matching array just to get a count of them?
>
> Who ever said that an array will be created. Did you bother to read
the
> documentation of keys. Obviously not. You have no understanding of
perl
> so stop pretending you know how it works.
At the risk of having Tad scold me again, I read the description of
keys() but it was the one given in my book "Perl From the Ground Up".
You, being a right and honorable gentlemen, were kind enough to point
out the parenthetical qualifier that is added in the perlfunc definition
(In a scalar context, returns the number of keys.) Later, Andrew was
kind enough to warmly explain how keys in a scalar context is just
returning an internal integer value, and not creating an intermediate
array.
>
> >
> >>
> >> > How about: %hash = ();
> >>
> >> > if (entries($hash) > 0 )
> >>
> >> Ew.
> >>
> >> What about
> >>
> >> if (%hash) {
> >> # ...
> >> }
> >>
> >> Much, much simpler, and then you don't even have to worry about
this
> >> problem.
> >
> >Asumming I just want to test emptiness. Thanks, just tried it, and it
> >worked, but I do have one comment - non-intuitive, non-lookupable,
> >obtuse.
>
> It's intuitive to anyone who has bothered learning a little perl. It's
> consistent with what happens in a scalar context. It's lookupable
since
> it is documented. perldata would be the obvious place to look.
Well I checked perldata, and did find:
"If you evaluate a hash in a scalar context, it returns a value that is
true if and only if the hash contains any key/value pairs."
But I believe that "learn" and "intuitive" are in conflict.
> It's not
> obtuse since it is the way perl is.
I feel that the use of the numbers 0, and non-zero to represent true or
false expressions in all languages that use it, be it Perl or C/C++, is
confusing to those learning the language.
>
> Now go away and use python.
How about if I buy you a couple of beers at the Monterey Perl
Conference? Could you then find it in your heart to forgive me for not
learning everything in the Perl HTML pages?
>
> --
> Sam
>
> There's no such thing as a simple cache bug.
> --Rob Pike
>
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
Date: Sun, 16 May 1999 07:40:32 GMT
From: andrew-johnson@home.com (Andrew Johnson)
Subject: Re: Perl "constructors"
Message-Id: <QDu%2.13005$L4.690932@news2.rdc1.on.home.com>
In article <w_t%2.141$fx5.427@news.rdc1.sfba.home.com>,
Stephen Warren <swarren@www.wwwdotorg.org> wrote:
[snip]
! IIRC... This'll blow your mind: In Perl (don't know about Python), a
! variable can hold a string and a numeric value at the *same* time...
!
! Of course, the string would just be a textual representation of the number
! stored, but...
not necessarily ...
#!/usr/bin/perl -w
use strict;
use builtin 'dualvar';
my $scalar = dualvar(42,'this is the string part');
print $scalar + 1,"\n";
print "$scalar\n";
__END__
prints:
43
this is the string part
regards
andrew
------------------------------
Date: 16 May 1999 07:47:30 GMT
From: sholden@pgrad.cs.usyd.edu.au (Sam Holden)
Subject: Re: Perl "constructors"
Message-Id: <slrn7jsu0h.72t.sholden@pgrad.cs.usyd.edu.au>
On Sun, 16 May 1999 07:21:51 GMT, armchair@my-dejanews.com wrote:
>In article <slrn7js8nd.d4q.sholden@pgrad.cs.usyd.edu.au>,
> sholden@cs.usyd.edu.au wrote:
>> On Sat, 15 May 1999 09:40:32 GMT, armchair@my-dejanews.com wrote:
>> >In article <ylzp366dm2.fsf@windlord.stanford.edu>,
>> > Russ Allbery <rra@stanford.edu> wrote:
>> >> armchair <armchair@my-dejanews.com> writes:
>> >>
>> >> > I can speak to this: connect() and prepare() should be member
>> >functions
>> >> > and not constructors as a member function can return a status
>code
>> >of
>> >> > success or various error codes. A constructor cannot.
>> >>
>> >> Constructors certainly can return various error codes, as well as
>> >success
>> >> or failure.
>> >
>> >And what does your code look like?
>> >
>> >#constructor...
>> >if ( success )
>> >{ return bless a; } else { return 0; }
>>
>> No since return 0 is not how you return false in perl. But since you
>can't
>> be bothered looking up simple things you just make an incorrect
>statement
>> and then use it to show perl isn't how you like.
>
>You are always on the defensive aren't you. I was trying to get the
>other fellow to be more explicit and complete and you take it as an
>attack on Perl and add another one of your ad hominem attacks, while
>also not answering the question.
I answered the question. I said look it up in the documentation.
Just use 'return;' not 'return 0;'.
So you would have...
return bless $ref if $success;
return;
Though you might like to use if...else or unless.
>
>
>>
>> >
>> >#caller
>> >
>> >my $reference = myclass->new();
>> >if ( $reference == 0 )
>> >{
>> > print "constructor failed\n";
>> >}
>> >
>> >Correct?
>>
>> No more likely the simple :
>> my $reference = myclass->new() || die "constructor failed";
>
>Again we have the same problem as with the other fellow. What does the
>code look like INSIDE THE CONSTRUCTOR.
>
>>
>> Perl does not restruct what a sub returns. It is not a strongly typed
>> language. You are placing stupid restrictions on perl that don't
>exist.
>
>Again you are incredibly, astonishingly, unbelievably defensive. I ask a
>question on how some fellow is writing his code (something he should
>have stated, but is mostly just interested in ad hominem barks), and you
>turn it into an an attack on Perl.
>
>
>> If you want you could return anything you feel like on failure. If you
>> want to return the string "I failed" then you can. If you want to
>return
>> the error code 42 then you can. If you want to return a reference to
>an
>> array of arrays of hashes to indicate error then you can.
>
>What did you return in your above example???:
>
>my $reference = myclass->new() || die "constructor failed";
undef.
>
>>
>> >>
>> >> > In any event, you can't get around the fact that constructors
>return
>> >a
>> >> > blessed reference. It's nice for functions that can fail, to
>return
>> >> > error codes. Or perhaps you are printing error messages and
>exiting
>> >your
>> >> > program when your constructors fail??
>> >>
>> >> Have you heard of exceptions?
>> >
>> >In C++ and Java, but not in Perl. Does it have them, and if so which
>> >perl HTML page section are they documented in?
>>
>> It's documented in perlfaq8 which you should have read before posting,
>but
>> you are obviously too stupid.
>
>I think there are going to be quite a few people upset at you referring
>to my desire to learn Perl as a demonstration of "obvious stupidity".
There are and I'll try to be nicer.
>
>>
>> It's also documented in perlfunc. It's mentioned in perltoc (how could
>you
>> not read that one?), and in perldelta, and perlfaq7, and I couldn't be
>> bothered checking elsewhere...
>
>Okay, I found a reference to exceptions.pl in perlfaq8, and references
>to klugeing exception handling via eval(), die(). Thanks Sam.
>>
>> >> > I don't think it is too much to ask for a function, a complement
>to
>> >> > "exists" if you will, that tells how many items are in a hash.
>> >>
>> >> What, like $count = keys %hash?
>> >
>> >Very expensive, not intuitive. What is the hash has 2000 items.
>Create
>> >a matching array just to get a count of them?
>>
>> Who ever said that an array will be created. Did you bother to read
>the
>> documentation of keys. Obviously not. You have no understanding of
>perl
>> so stop pretending you know how it works.
>
>At the risk of having Tad scold me again, I read the description of
>keys() but it was the one given in my book "Perl From the Ground Up".
>You, being a right and honorable gentlemen, were kind enough to point
>out the parenthetical qualifier that is added in the perlfunc definition
>(In a scalar context, returns the number of keys.) Later, Andrew was
>kind enough to warmly explain how keys in a scalar context is just
>returning an internal integer value, and not creating an intermediate
>array.
>
>>
>> >
>> >>
>> >> > How about: %hash = ();
>> >>
>> >> > if (entries($hash) > 0 )
>> >>
>> >> Ew.
>> >>
>> >> What about
>> >>
>> >> if (%hash) {
>> >> # ...
>> >> }
>> >>
>> >> Much, much simpler, and then you don't even have to worry about
>this
>> >> problem.
>> >
>> >Asumming I just want to test emptiness. Thanks, just tried it, and it
>> >worked, but I do have one comment - non-intuitive, non-lookupable,
>> >obtuse.
>>
>> It's intuitive to anyone who has bothered learning a little perl. It's
>> consistent with what happens in a scalar context. It's lookupable
>since
>> it is documented. perldata would be the obvious place to look.
>
>Well I checked perldata, and did find:
>"If you evaluate a hash in a scalar context, it returns a value that is
>true if and only if the hash contains any key/value pairs."
>
>But I believe that "learn" and "intuitive" are in conflict.
>
>> It's not
>> obtuse since it is the way perl is.
>
>I feel that the use of the numbers 0, and non-zero to represent true or
>false expressions in all languages that use it, be it Perl or C/C++, is
>confusing to those learning the language.
Perl doesn't use 0 to represent false. False in perl is anything which
evaluates to "" or 0 or "0" and possibly some things I can't remember.
Of course it depends on context as well. 0 isn't false in a list context.
It's in the documentation anyway. Perl uses anything that isn't false
as true.
To return false in perl you simply use return; So here's a sub that
returns false.
sub false { return;}
>
>>
>> Now go away and use python.
>
>How about if I buy you a couple of beers at the Monterey Perl
>Conference? Could you then find it in your heart to forgive me for not
>learning everything in the Perl HTML pages?
I'd have a lot of trouble getting to the Monterey Perl Conference I
suspect.
I'm sorry for calling you a stupid idiot all the time. I assumed you
were intentionally ignoring what everyone had said over and over again.
I guess in reality you were just using a book instead of the
documentation.
Too much topmind exposure on my part I guess...
I still think that if you hate all the things you say you hate, that
perl is not the language for you. Python isn't either. I'm not sure
what is since I like the things you don't and thus haven't looked
for what you want.
--
Sam
Of course, in Perl culture, almost nothing is prohibited. My feeling is
that the rest of the world already has plenty of perfectly good
prohibitions, so why invent more? --Larry Wall
------------------------------
Date: Sun, 16 May 1999 07:56:41 GMT
From: design@raincloud-studios.com (Charles R. Thompson)
Subject: Re: Perl "constructors"
Message-Id: <MPG.11a8459c453c20f39896cb@news>
In article <FYt%2.140$fx5.352@news.rdc1.sfba.home.com>, Stephen Warren
says...
> You obviously never typed in 1000-line listings
> of BASIC programs from computer magazines!
Man... now *everyone's* gonna know where I get my scripts! Thanks alot.
:P
--
CT
------------------------------
Date: Sun, 16 May 1999 07:48:26 GMT
From: armchair@my-dejanews.com
Subject: Re: Perl "constructors"
Message-Id: <7hlt8a$b6i$1@nnrp1.deja.com>
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?
>
> > 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.
> It turns out that most of the reason why constructors fail in C++ is
due
> to memory allocation problems, and in Perl you don't have to worry
about
> that.
I haven't seen any C++ code that actually checks for a memory allocation
failure in a constructor (it should for absolute robustness, but just
haven't seen anyone do it - it is that rare). On today's machines with
large real memory, and huge virtual memory, a memory allocation failure
doesn't seem to happen unless or because there is an endless loop
situation.
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.
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".
> So it's actually fairly rare for constructors to fail in Perl,
and
> you usually don't have to worry about it. If you do, the constructor
can
> document that it throws exceptions, and you can catch them if you
want.
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. That is not a function of the language, but just the
nature of the problem. Connect to a database inside a constructor in
Perl, Java or C++ or even Python or Eiffel, and if the database is down,
and I am assuming that my object once constructed is "connected", then I
have failed in my constructor, regardless of language.
>
> If you're writing a quick little program, you usually don't need to
catch
> them. Just let them propagate up and cause your program to exit.
Fair enough. Now I just have to learn how to do it...
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
Date: Sat, 15 May 1999 23:01:19 -0700
From: lr@hpl.hp.com (Larry Rosler)
Subject: Re: PERLFUNC: keys - retrieve list of indices from a hash
Message-Id: <MPG.11a7ff0b2890d3e6989a74@nntp.hpl.hp.com>
[Posted and a courtesy copy sent.]
In article <373dcdab@cs.colorado.edu> on 15 May 1999 13:40:27 -0700, Tom
Christiansen <perlfaq-suggestions@perl.com> says...
...
> @keys = keys %ENV;
> @values = values %ENV;
> while ($#keys >= 0) {
That seems like an awkward way to write
while (@keys) {
> print pop(@keys), '=', pop(@values), "\n";
> }
--
(Just Another Larry) Rosler
Hewlett-Packard Company
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: Sun, 16 May 1999 06:45:44 GMT
From: "Stephen Warren" <swarren@www.wwwdotorg.org>
Subject: Re: perltootc - OO Tutorial for Class Data in Perl
Message-Id: <sQt%2.135$fx5.245@news.rdc1.sfba.home.com>
Some comments in the form of a unified diff. I hope people can grok this,
but I figured it would be the most convenient way to merge them into the
original .pod file...
A couple of fixes (e.g. double-type words) are made inline.
My comments have each inserted line prefixed with XX for easy searching
after a patch (except for possibly some extra empty lines after the
comments)
Hope it all makes sense...
P.S. I managed to follow 99% of this. The 'original' you posted the other
day got a bit heavy, but maybe I wasn't concentrating then!
--- perltootc.pod Sat May 15 22:34:56 1999
+++ perltootc-updated.pod Sat May 15 23:46:50 1999
@@ -64,7 +64,7 @@
state of instance data on an object. This provides for a clear firewall
between interface and implementation.
-You should allow access to access class data either through the class
+You should allow access to class data either through the class
name or through any object of that class. If we assume that $an_object
is of type Some_Class, and the &Some_Class::population_count method
accesses class data, then these two invocations should both be possible,
@@ -85,7 +85,7 @@
Class data provide a much cleaner solution that emulation through
instance
data. Unlike more restrictive languages like C++, where these are called
static data members, Perl provides no formal, syntactic mechanism to
-declare class data, any more than it provides a, syntactic mechanism
+declare class data, any more than it provides a syntactic mechanism
to declare instance data. Instead, Perl provides the developer with
a broad set of powerful but flexible features that the creative mind
can use to produce a custom design uniquely crafted to the particular
@@ -504,7 +504,7 @@
Inquisitive folk can easily access data in the class meta-object, making
it easy to dump the complete class state using an external mechanism such
as for debugging or to implement a persistent class. This works because
-the class meta-object is a package variable, has a well-known name,
+the class meta-object is a package variable, has a well-known name and
clusters all its data together. (To be honest, transparent persistence
is not always feasible, but it's certainly an appealing idea.)
@@ -637,7 +637,7 @@
=head2 Translucent Attributes
The package's eponymous hash be used for more than just containing
-per-class, global state data. It can also server as a sort of template
+per-class, global state data. It can also serve as a sort of template,
containing default settings for object attributes. These default
settings
can then be used in contructors for initialization of a particular
object.
The class's eponymous hash can also be used to implement I<translucent
@@ -688,11 +688,18 @@
take the color its parent held, which happens to now be "chartreuse".
That's because the constructor will always use the invoking object as
its template for initializing data attributes. When the constructor's
-invoking object is the class name, the object used as template is is the
-eponymous. But when the invoking object is a reference to an
instantiated
+invoking object is the class name, the object used as template is the
+eponymous meta-object. But when the invoking object is a reference to an
instantiated
object, the &spawn constructor uses the existing object as a template
and copies in its values instead of leaving them translucently undefined.
+XX Stephen Warren comment:
+XX The last sentence might be a little confusing. I first read it to mean
+XX that after $ob4=$ob3->spawn(); even those values in $ob3 that were
+XX translucent wouldn't be in $ob4. In retrospect, it does mean what you
say,
+XX since it actually means it will copy what keys exist and hence
everything
+XX else *will* stay translucent, but that took thinking about:-)
+
$ob4 = $ob3->spawn();
print $ob4->color(); # prints "chartreuse"
@@ -734,6 +741,13 @@
$ob4->color(undef); # back to "azure"
+XX Stephen Warren comment
+XX Depends on implementation... Since this is before the code, it might
+XX help to note that we are using defined() rather than exists() for the
+XX determination of translucency below. Otherwise, one's first though on
+XX reading the above might be that it doesn't work. Of course, on reading
+XX the code, it all became clear.
+
Here's a complete implementation of Some_Class as described above.
package Some_Class;
@@ -759,6 +773,12 @@
# init fields from invoking object, or omit if
# invoking object is the class to provide translucency
%$self = %$obclass unless $class;
+XX Stephen Warren comment
+XX I might be stupid, but doesn't $class always evaluate to true?
+XX I can't quite work this bit out...
+XX I know $class should always contain the package name, which is
+XX also the name of the eponymous meta-object. Is this using
+XX a symbolic reference deref for existence of the symbol or something?
return $self;
}
@@ -828,6 +848,15 @@
Translations to C++, Java, and Python have been left as exercises for
the reader. Be sure to send us mail as soon as you're done.
+XX Stephen Warren comment
+XX Java does at least have hash-tables, so it could easily use the same
+XX scheme of things. Of course, since an int isn't a java.lang.Object and
+XX java.lang.Hashtable only stores objects, we'd have to do a lot of
+XX int -> java.lang.Integer and back (and so on for other primitive
types).
+XX As far as the automatic closure creation, I've always wanted the
+XX opposite of introspection - maybe it'd be called impersonation -
+XX the ability to add methods at run-time into an existing class...
+
=head1 Class Data as Lexical Variables
=head2 Privacy and Responsibility
@@ -841,6 +870,9 @@
anything within a class save through the mediated access of
its documented interface; in other words, through its method invocations.
+XX Stephen Warren comment:
+XX _classobj, anyone? <grin>
+
But if they do go messing around, it's not your fault--it's theirs.
Perl believes in individual responsibility rather than mandated control.
Perl respects you enough to let you choose your own preferred level of
@@ -1189,6 +1221,12 @@
I use the hypothetical our() syntax for package variables. It works
like use vars, but looks like my(). It should be 5.006, I hope.
+
+XX Stephen Warren comment
+XX I guess this has probably been discussed elsewhere already, but...
+XX I wonder about the name our(). I can certainly see the similarity
+XX to my(), but wonder if sym(), declare(), define() might not be
+XX slightly more immediately obvious to the casual observer? Who knows.
The usual mealy-mouthed package mungeing doubtless applies to setting
up names of instance data. For example, C<$self-E<gt>{ObData1}> should
--
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
------------------------------
Date: Sun, 16 May 1999 06:09:29 GMT
From: armchair@my-dejanews.com
Subject: Re: TROLL ALERT (Re: Perl "constructors")
Message-Id: <7hlneo$6ma$1@nnrp1.deja.com>
In article <ylk8u94yq4.fsf@windlord.stanford.edu>,
Russ Allbery <rra@stanford.edu> wrote:
> Arved Sandstrom <Arved_37@chebucto.ns.ca> writes:
>
> > But a fixed name for an object constructor ('new') is a feature of
C++
> > and Java, for example. Why should Perl be defiantly different?
>
> I don't think this is quite entirely true.
>
> 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. They can be "overloaded - an odd
C++ term" in that you have more than one constructor (all with the same
name - the name of the class) but each one will take a different input
parameter list.
CPlusClass my_instance; // call to CPlusClass(void)
CPlusClass my_inst2.(10,23,30); // call to CPlusClass(int, int, int)
"new" is a reserved word that is used to dynamically allocate memory.
In Java "new" is also a reserved word (and it appears to function more
as documentation than anything else), and is used in the creation of
objects (not dynamic memory as in C++), but it is not the constructor
name, the constructor name(s) are exactly as done in C++.
JavaClass myInstance = new JavaClass(); // new is keyword and
//JavaClass() is the constructor
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.
>
> --
> #!/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: 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 5681
**************************************
