[12070] in Perl-Users-Digest
Perl-Users Digest, Issue: 5670 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat May 15 07:07:20 1999
Date: Sat, 15 May 99 04:00:15 -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 Sat, 15 May 1999 Volume: 8 Number: 5670
Today's topics:
Re: FAQ 4.14: How can I find the Julian Day? (Martin Vorlaender)
Hlp! XSUBPP has a matter. <okpolis@okpolis.joo.net>
Need help to modify email checker. <mrblue@pd.jaring.my>
Re: Perl "constructors" armchair@my-dejanews.com
Re: Perl "constructors" armchair@my-dejanews.com
Re: Perl "constructors" armchair@my-dejanews.com
Re: Perl "constructors" armchair@my-dejanews.com
Re: Perl "constructors" armchair@my-dejanews.com
Re: Perl "constructors" armchair@my-dejanews.com
Re: Perl "constructors" armchair@my-dejanews.com
Perl Scripts for NT <carvdawg@patriot.net>
Re: Where is LWP: POP3Client.pm? (Toby Poynder)
Special: Digest Administrivia (Last modified: 12 Dec 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 15 May 1999 12:10:19 +0200
From: martin@RADIOGAGA.HARZ.DE (Martin Vorlaender)
Subject: Re: FAQ 4.14: How can I find the Julian Day?
Message-Id: <373d480b.524144494f47414741@radiogaga.harz.de>
David L. Cassell (cassell@mail.cor.epa.gov) wrote:
: Larry Rosler wrote:
: > The system of Julian days should not be confused with the simpler system
: > of the same name which associates a date with the number of days elapsed
: > since January 1st of the same year (according to which 2000-12-31 is day
: > 366 of the year 2000).
: So there's at least one more pseudo-julian-day which the
: reader might want, which is easily handled in Perl. Does this
: FAQ need a pop quiz at the front?
To relief some of the confusion, here's an article on a different question
that gives answers.
cu,
Martin
COMPONENT: SYSTEM TIME OP/SYS: VMS, Version 4.n
LAST TECHNICAL REVIEW: 06-APR-1988
SOURCE: Customer Support Center/Colorado Springs
QUESTION:
Why is Wednesday, November 17, 1858 the base time for VAX/VMS?
ANSWER:
November 17, 1858 is the base of the Modified Julian Day system.
The original Julian Day (JD) is used by astronomers and expressed in days
since noon January 1, 4713 B.C. This measure of time was introduced by
Joseph Scaliger in the 16th century. It is named in honor of his father,
Julius Caesar Scaliger (note that this Julian Day is different from the
Julian calendar named for the Roman Emperor Julius Caesar!).
Why 4713 BC? Scaliger traced three time cycles and found that they were
all in the first year of their cyle in 4713 B.C. The three cycles are 15,
19, and 28 years long. By multiplying these three numbers (15 * 19 * 28
= 7980), he was able to represent any date from 4713 B.C. through 3267 A.D.
The starting year was before any historical event known to him. In fact,
the Jewish calendar marks the start of the world as 3761 B.C. Today his
numbering scheme is still used by astronomers to avoid the difficulties of
converting the months of different calendars in use during different eras.
So why 1858? The Julian Day 2,400,000 just happens to be November 17, 1858.
The Modified Julian Day uses the following formula:
MJD = JD - 2,400,000.5
The .5 changed when the day starts. Astronomers had considered it more
convenient to have their day start at noon so that nighttime observation times
fall in the middle. But they changed to conform to the commercial day.
The Modified Julian Day was adopted by the Smithsonian Astrophysical Obser-
vatory (SAO) in 1957 for satellite tracking. SAO started tracking satellites
with an 8K (non-virtual) 36-bit IBM 704 computer in 1957, when Sputnik was
launched. The Julian day was 2,435,839 on January 1, 1957. This is
11,225,377 in octal notation, which was too big to fit into an 18-bit field
(half of its standard 36-bit word). And, with only 8K of memory, no one
wanted to waste the 14 bits left over by keeping the Julian Day in its own
36-bit word. However, they also needed to track hours and minutes, for which
18 bits gave enough accuracy. So, they decided to keep the number of days in
the left 18 bits and the hours and minutes in the right 18 bits of a word.
Eighteen bits would allow the Modified Julian Day (the SAO day) to grow as
large as 262,143 ((2 ** 18) - 1). From Nov. 17, 1858, this allowed for seven
centuries. Using only 17 bits, the date could possibly grow only as large as
131,071, but this still covers 3 centuries, as well as leaving the possibility
of representing negative time. The year 1858 preceded the oldest star catalog
in use at SAO, which also avoided having to use negative time in any of the
satellite tracking calculations.
This base time of Nov. 17, 1858 has since been used by TOPS-10, TOPS-20, and
VAX/VMS. Given this base date, the 100 nanosecond granularity implemented
within VAX/VMS, and the 63-bit absolute time representation (the sign bit must
be clear), VMS should have no trouble with time until:
31-JUL-31086 02:48:05.47
At this time, all clocks and time-keeping operations within VMS will suddenly
stop, as system time values go negative.
Note that all time display and manipulation routines within VMS allow for
only 4 digits within the 'YEAR' field. We expect this to be corrected in
a future release of VAX/VMS sometime prior to 31-DEC-9999.
--
| Martin Vorlaender | VMS & WNT programmer
VMS is today what | work: mv@pdv-systeme.de
Microsoft wants | http://www.pdv-systeme.de/users/martinv/
Windows NT 8.0 to be! | home: martin@radiogaga.harz.de
------------------------------
Date: Sat, 15 May 1999 18:51:43 +0900
From: =?euc-kr?B?udrBvrq5IChQYXJrLCBKb25nLVBvcmsp?= <okpolis@okpolis.joo.net>
Subject: Hlp! XSUBPP has a matter.
Message-Id: <7hjg8t$ipa$1@news2.kornet.net>
Hi. I follow example1 of perxstut document. But it's work strange.
c:\www\gad\test>perl Makefile.PL
Usage: xsubpp [-v] [-C++] [-except] [-prototypes] [-noversioncheck] [-nolinenumb
ers] [-s pattern] [-typemap typemap]... file.xs
Writing Makefile for Mytest
So I add a line for debugging into c:\perl\lib\extutils\xsubpp file.
$usage = "Usage: x<skip>. file.xs\nARGV is @ARGV\n";
Please Help me. I had this.
c:\www\gad\test>perl Makefile.PL -stastic
Usage: xsubpp [-v] [-C++] [-except] [-prototypes] [-noversioncheck] [-nolinenumb
ers] [-s pattern] [-typemap typemap]... file.xs
ARGV is temp000 2
Writing Makefile for Mytest
Thank You.
------------------------------
Date: Sat, 15 May 1999 17:23:01 +0800
From: "Blue" <mrblue@pd.jaring.my>
Subject: Need help to modify email checker.
Message-Id: <7hjeej$k1j$1@news5.jaring.my>
My form-mail (not written by me, I am one cgi-idiot) contains the portion
shown below to check for
email input in a form. Can you please tell me what it actually checks for?
Is it possible to modify it so that it only accept the email input when ...
(a) there is "@" and .....
(b) there is EITHER "tm.net.my" OR "jaring.my"
Because I want to accept only email address from any of these two ISPs.
Hotmail addressed will not be accepted.
Typical email addresses from these two ISP are:
XXXXXX@tm.net.my and XXXXXX@XX.jaring.my (only the "X"s are variables)
Thanks from Mr.Blue
_______________________________________
if ($FORM{'email'}) {
unless ($FORM{'email'} =~ /\w+@\w+.\w+/)
------------------------------
Date: Sat, 15 May 1999 08:49:02 GMT
From: armchair@my-dejanews.com
Subject: Re: Perl "constructors"
Message-Id: <7hjcdu$ns8$1@nnrp1.deja.com>
In article <373cf704@cs.colorado.edu>,
tchrist@mox.perl.com (Tom Christiansen) wrote:
> [courtesy cc of this posting sent to cited author via email]
>
> In comp.lang.perl.misc,
> 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.
>
> Again, you're deeply confused. There's no such thing as a member
> function in Perl. We have methods. That's it. All else is
convention
> alone, whether it be class methods, object methods, or constructors.
> Those aren't different things.
Method, member function, different names for the same thing. You know
what I meant. In any event, a constructor returns a reference to the
object just created, not an error code. 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.
>
> If you so very badly care to abuse yourself with C++, please get thee
> hence and trouble us no more. If you want to learn perl, drop the
> bullshit.
Am I the only person who feels you are extremely defensive about Perl?
>
> :A constructor cannot. I would assume you
> :are adding:
> :
> :if ( $dbh->MadeConnection() )
>
> Nope. I'll take an exception if it fails, or I'll check the
> return value.
That's the point. The return value of a constructor is a reference to
the object just created, not an error code. And I assume "taking an
exception" means you will allow the program to crash with no graceful
shutdown or meaningful error reporting or second chance.
>
> :I can't figure out what is going on here.
>
> That's hardly my fault.
It's not. Is it Perl's fault?
>
> :Am I correct
> :in believing that each class/module only has one subroutine in which
> :it does a bless?
>
> Of course not.
So in effect, Perl has a capability to "overload" a classes constructors
then, I take it.
>
> And for the record, a class is not a module, although often modules
> implement classes.
>
What is the most classes that a module could implement? What is the most
packages that a module could define?
> :In any event, you can't get around the fact that
> :constructors return a blessed reference.
>
> Oh, good. You're wrong again. I most certainly can.
Well, let's see some code my good man.
>
> :It's nice for functions that
> :can fail, to return error codes.
>
> You're revealing your improper education again. I'm sorry.
Well, to be correct functions that fail should actually throw
exceptions, but that is not available in Perl, so returning an error
code, and checking it, is the way to go if you want "robust" code.
>
> :I notice a bit of C, along with some DBASE III. And probably some
Basic
> :as well.
>
> Really, child, haven't you something else to do than to insult
> what you cannot understand?
Really, old man, are you so smitten by a programming language that you
take a legitimate comparison to other languages as an insult?
>
> :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.
>
> RTFM. We have one. You missed it.
Me and the people who responded to my post. That leaves only you who
sees it.
>
> :Fair enough, but they will end up speaking it someday anyway, so in
both
> :cases I may be wrong today, but ultimately right.
>
> Que la tomes por culo, anglo bigot.
Did I mention you sound bitter?
>
> --tom
> --
> "We stand on the shoulders of giants and kick
> their ears whenever we feel like it." --Larry Wall
>
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
Date: Sat, 15 May 1999 09:30:28 GMT
From: armchair@my-dejanews.com
Subject: Re: Perl "constructors"
Message-Id: <7hjerk$p8g$1@nnrp1.deja.com>
In article <slrn7jpv03.871.sholden@pgrad.cs.usyd.edu.au>,
sholden@cs.usyd.edu.au wrote:
> On Sat, 15 May 1999 03:58:15 GMT, armchair@my-dejanews.com wrote:
> >In article <373c24e3@cs.colorado.edu>,
> > tchrist@mox.perl.com (Tom Christiansen) wrote:
> >> [courtesy cc of this posting sent to cited author via email]
> >>
> but I will certainly not be at service this weekend.
>
> Reading the documentation that tells you how to construct objects of
the
> type your having to use should be easy enough. If it's not documented
> then that's hardly perl's fault. Grep for bless and you have your
answer.
> It't not like it's difficult or anything.
Instead of enforcing a specific constructor name, "just do the
non-difficult - grep for bless"?? Quit pulling my leg! When I am reading
someone's code, I want to be rolling along and see a new() and know
immediately that's the constructor, not see Barney() here and Fred()
there and BamBam() there and have to keep referring to documentation to
see what the constructor name was.
>
> >
> >
> >>
> >> :I think this should be changed.
> >>
> >> You've clearly not thought about this very much. First off, you
have
> >> not provided a detailed analysis of the pros and cons of the
current
> >> approach compared with your suggested mutilation. More
importantly,
> >> at least five years worth of historical precedent laughs in your
face.
> >>
> >> Here's a constructor:
> >>
> >> $dbh = DBI->connect("dbi:mysql:somedb:server.host.dom:3306",
> >> "username", "password")
> >>
> >> And here's another one:
> >>
> >> $sth = $dbh->prepare(<<EO_SELECT)
> >> SELECT name,salary FROM employees WHERE salary > $limit
> >> EO_SELECT
> >
> >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. I would assume
you
> >are adding:
>
> How can you have a DBI object that is not connected? It doesn't make
sense.
> Just because you have to do it like that in C++ doesn't mean you have
to
> in perl...
C++ would allow you to try and make a connection as part of a
constructor. It places no restrictions on what a constructor does
besides initialize the object. A DBI object that is not connected would
be an unconnected DBI object.
>
> If the connection failed for some reason you would return undef. C++
doesn't
> do that because C++ isn't perl.
my $reference = my_class->connect();
So you are saying that one can do:
if ( $reference == undef )
to see if the object was created (i.e. made a successful connection)
>
> A constructor indicates the error with undef. That allows the user to
simply
> say || die "Unable to connect" or whatever.
Where's the rest of the statement?
$my_reference = my_class->connect() || or die "see ya";
Is that it??
>
> As I said before learn some perl before you start commenting on it's
problems.
> It has some, the one's you see don't exist though, you just don't know
the
> language.
If a DBI object should always be connected, as you imply, then there is
nothing wrong with $reference = DBI->new() as the connection is a
given.
>
> >
> >if ( $dbh->MadeConnection() )
> >
> >and
> >
> >if ( $sth->Prepared() )
> >
> >in your code?
>
> No '|| die' with the constructor. Maybe not die, maybe something less
fatal
> if it's not a fatal error.
And in the constructor you do:
if ( connection_made )
{
return bless $self;
}
else
{
return undef;
}
Is that what you are saying?
> You have it wrong. A reference can reference any other data structure.
> By using something other than a reference you restrict what you can
> use. Can I use a single int as an object in C++, no I have to make a
struct
> like thing which has an int as it's only data member. Can I use a
single
> scalar as an object in perl, yes just bless a reference to that
scalar.
I am aware that a reference can reference any other data structure. I
was requesting multiple data members in the class, rather than just one,
a reference.
A single int in a C++ object is no more complicated than a Perl object
that contains a reference to what the programmer is proposing should be
an int - and C++ objects do not require separate source files for each
object defined. They both have one data member. And C++ has pointers as
well, so it could have one data member in the class that points to a
complicated data nested data structure as well.
> >Short time. Correct. Not true - I have read the standard
documentation
> >and have a couple of books. I should have said "associative array",
then
> >I would have still looked bad, but I would have been correct.
>
> Only if you like using old outdated terminology...
No, I would have been correct. The "looked bad" part had to do with
whether it was "outdated terminology".
>
> >
> >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. I
seems
> >silly to have to create an array from a hash, then assign an array to
a
> >scalar (a silly event in itself) to get the number of items in a
hash.
>
> If you don't like context significant stuff (assigning an array to a
scalar
> actually doing what you probably want) then run away from perl and use
> some other language. Python is good. It has much more integrated OO.
It's
> a bit like perl in some respects. Why don't you go and torture python
> instead.
>
> You obviously don't like the way perl does things. The simple solution
is
> to not use perl. There are some languages I don't like, so I don't use
> them. If your job involves perl and you don't like perl then do
yourself
> a favour and find a job that doesn't use the things you hate. Your
stress
> levels, and family will thank you for it.
You are getting almost as defensive as the other fellow. It appears that
there is stress here, but I certainly am not the one feeling it. Perl
has clearly changed over the years, and I am sure it will change
regardless of any suggestions I make. I am sure that there were many of
you who railed against anyone who said a few years back "Hey, how about
objects in Perl?" But certainly your implication that those languages
could not be anymore supercilious is well taken.
>
> >How about:
> >%hash = ();
> >
> >if (entries($hash) > 0 )
>
> $hash is completely seperate from %hash. Learn some perl.
Oops, a typo. Let's try it again:
%hash = ();
if (entries(%hash) > 0 )
>
> >{
> > ... process hash
> >}
> >
> >which leads to
> >@array = ();
> >
> >if ( entries(@array) > 0 )
> >{
> > ... process array
> >}
>
> Feel free to write that entries() sub if you like. Perl does it a
different
> way. I guess you'd want a function to tell you if there was an even
number
> of elements in the hash as well. Since counting them, and then
checking if
> that is even seems a silly thing to do.
You miss the point. I could write an entries sub, but it would be just
as slow as creating an array from a hash and then assigning it to a
scalar (simply to find out how many items are in the hash). Since there
is some internal structure that each uses, there must be some internal
structure or variable that is holding (or could hold) the number of
entries in the hash and that could be QUICKLY returned via a Perl
internal C subroutine. Not to mention people wanting to see how to get
the number of entries in a hash (probably to determine if it is empty or
not in most cases) can find that info in discussions about hashes in
books or perldata or perlfunc and not have to be chastised for not
looking at a faq which reveals slow and expensive code that is based on
a non-intuitive and confusing concept - "context significance".
>
> --
> Sam
>
> testing? What's that? If it compiles, it is good, if it boots up it is
> perfect.
> --Linus Torvalds
>
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
Date: Sat, 15 May 1999 09:40:32 GMT
From: armchair@my-dejanews.com
Subject: Re: Perl "constructors"
Message-Id: <7hjfeg$pl9$1@nnrp1.deja.com>
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; }
#caller
my $reference = myclass->new();
if ( $reference == 0 )
{
print "constructor failed\n";
}
Correct?
>
> > 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?
>
> > 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?
>
> > 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.
>
> --
> #!/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: Sat, 15 May 1999 09:40:17 GMT
From: armchair@my-dejanews.com
Subject: Re: Perl "constructors"
Message-Id: <7hjfe1$pl8$1@nnrp1.deja.com>
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; }
#caller
my $reference = myclass->new();
if ( $reference == 0 )
{
print "constructor failed\n";
}
Correct?
>
> > 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?
>
> > 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?
>
> > 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.
>
> --
> #!/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: Sat, 15 May 1999 09:56:13 GMT
From: armchair@my-dejanews.com
Subject: Re: Perl "constructors"
Message-Id: <7hjgbt$q9e$1@nnrp1.deja.com>
In article <ylhfpf6jyw.fsf@windlord.stanford.edu>,
Russ Allbery <rra@stanford.edu> wrote:
> armchair <armchair@my-dejanews.com> writes:
>
> > Why don't you just make your case in this forum. I have read those
> > documents and did not reach the same conclusion you have. Perl would
not
> > have to be C++ to have a fixed name for constructors.
>
> No, but it would be a violation of a very core concept in Perl. Perl
is a
> libertarian language. Perl believes in individual responsibility
rather
> than mandated control. Perl believes that the programmer is
intelligent
> and capable of making their own decisions. Perl believes that if you
> create an object with something other than new, you have a good reason
for
> that.
>
Where are the core concepts of Perl stated?
> > And since C++ is used for major projects, whereas Perl is used on
more
> > "quick and dirty" small projects, I am very surprised that you would
> > feel that the Perl way is the right way.
>
> Most projects are small.
Perhaps a majority are, and perhaps a majority of code that is written
is never modified by anyone other than the author, but in the cases
where it is, standardization and rules that allow compile time error
catching are of great value.
>
> > It is much easier to work with discrete variables rather than
> > subscripted array variables. I can remember that total_attendees is
the
> > number of peope who attended the meeting a lot easier than I can
> > $rSelf->[10] is.
>
> Straw man. You're using an array when you have no reason to do so,
and
> you're using ugly Hungarian notation to intentionally obfuscate your
> variable.
Wrong. I am using an array because I have created an object that needs
to hold multiple scalars, one of which is total_attendees. I have no
choice but to $rSelf->[10]. You should have attacked me for not using a
hash to store the data where I could have written
$rSelf->{"total_attendees}. And surely a proponent of Perl, a language
that you have just described as libertarian, so libertarian constructors
can be of any name, would not actually be complaining about a simple
user-defined variable name????
>
> $$self{attendees} is not hard to type and is quite clear, as well as
> making it explicit that the data that you're accessing is stored
inside
> the object (rather than being a lexical or package variable or
something
> else).
Oh, you did suggest a hash.
> C++ on the other hand gives no visual clues at all about such
> matters in the actual code, making reading C++ code an exercise in
> multiple windows to find all of the hidden gotchas and action at a
> distance.
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;
>
> > I have not run into any brick wall, but having worked with C++, I
can
> > assure you that having only one reference in an object point to it's
> > data (none of which is a struct or true multi-dimensional array)
does
> > not lead to a great convenience in programming.
>
> Having worked with both C++ and Perl, I can assure you that it does.
> There, my statement has just as much support as yours does.
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.
>
> --
> #!/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: Sat, 15 May 1999 10:23:35 GMT
From: armchair@my-dejanews.com
Subject: Re: Perl "constructors"
Message-Id: <7hjhv6$r17$1@nnrp1.deja.com>
In article <slrn7jptpa.871.sholden@pgrad.cs.usyd.edu.au>,
sholden@cs.usyd.edu.au wrote:
> On Sat, 15 May 1999 03:31:11 GMT, armchair@my-dejanews.com wrote:
> >In article <7hh9rs$58m$1@nnrp1.deja.com>,
> > John Porter <jdporter@min.net> wrote:
> >> In article <7hh079$ueo$1@nnrp1.deja.com>,
> >> armchair@my-dejanews.com wrote:
>
> >> > And an object should be able to consist of more than just a
> >reference.
> >>
> >> What would that gain you that you don't already have with
references?
> >> Even if there was more than a reference, how would you get at it?
> >> All data structures in Perl -- other than the basic scalar, array,
> >> and hash -- are build using references. Overlaying the class
> >> mechanism on this was a natural thing to do and leads to great
> >> convenience in programming. Have you run into some kind of brick
> >> wall as a result of objects only being references?
> >
> >It is much easier to work with discrete variables rather than
> >subscripted array variables. I can remember that total_attendees is
the
> >number of peope who attended the meeting a lot easier than I can
> >$rSelf->[10] is.
>
> I'd use $rSelf->{total_attendees}. If you would actually use a
reference to
> an array like that then you either don't know perl, or you are an
> optimisation idiot...
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?
>
> In fact since I'm using a hash not a stupid C++ variable name, I could
> get rid of the damn _ if I felt like it and use :
>
> $rSelf->{'total attendees'}
>
> Maybe you should learn some perl or go back to C++.
Actualy, I haven't left C++. Would I be correct in surmising that the
slogan of this newsgroup is not "everybody join in".
>
> >I have not run into any brick wall, but having worked
> >with C++, I can assure you that having only one reference in an
object
> >point to it's data (none of which is a struct or true
multi-dimensional
> >array) does not lead to a great convenience in programming.
>
> A hash is what perl uses for a struct, it does everything a struct
does and
> then some...
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.
>
> A multi-dimensional array would be $mda[4][3][2][1][0] = 'bill'; How
> is that not a 'true multi-dimensional' array?
>
> Maybe you should learn some perl before start to complain about what
> it can't do...
The "one reference per object" is only a minor complaint. 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).
And I am trying to learn Perl, but have run into some mixed opinions on
whether or not I am doing the right thing...
>
> --
> Sam
>
> If your language is flexible and forgiving enough, you can prototype
> your belief system without too many core dumps.
> --Larry Wall
>
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
Date: Sat, 15 May 1999 10:37:07 GMT
From: armchair@my-dejanews.com
Subject: Re: Perl "constructors"
Message-Id: <7hjioj$rks$1@nnrp1.deja.com>
In article <ylk8ub6k7p.fsf@windlord.stanford.edu>,
Russ Allbery <rra@stanford.edu> wrote:
> armchair <armchair@my-dejanews.com> writes:
>
> > It doesn't??? It's easier to stuff varibles inside of an array and
> > remember which is which and access them via subscripts rather than
name
> > them and access them by name discretely?? Or stuff them in a hash
and
> > have to use that bulky syntax to get them out?? You're pulling my
leg,
> > but you almost had me. But there is the lack of a record construct
in
> > Perl. Surely we see eye to eye about that oversight.
>
> record.field is exactly two fewer characters than $record{field}. I
don't
> find this a tremendous hardship. So no, we don't see eye to eye about
> that; I don't consider it an oversight in the slightest.
Okay, I take your point regarding syntax similarity. It just takes
some getting used to I suppose. But the oversight was referring to
another difference: records are fixed in the number and type (but not
possible in Perl) of fields they hold, whereas a hash or array can hold
0 to n fields and has to be checked if the code is going to be "robust"
and handle invalid passed parameters gracefully.
>
> --
> #!/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: Sat, 15 May 1999 06:56:24 +0100
From: Marquis de Carvdawg <carvdawg@patriot.net>
Subject: Perl Scripts for NT
Message-Id: <373D0C88.2776E396@patriot.net>
I've been looking for sites with NT Perl Scripts posted and
haven't found many (any, really) so I posted my own at:
http://www.patriot.net/users/carvdawg/perl.html
If something there works for you, great. I'll be posting more,
as I finish things up. If you would like to see something that
isn't there, or would like something modified, contact me.
------------------------------
Date: Sat, 15 May 1999 09:17:41 GMT
From: tobyp@dial.pipex.com (Toby Poynder)
Subject: Re: Where is LWP: POP3Client.pm?
Message-Id: <373d3afb.88492612@news.dial.pipex.com>
On Sat, 01 May 1999 11:08:37 GMT, alastair@calliope.demon.co.uk
(Alastair) wrote:
>.........
>Install the same way as any module ;
>
>perl Makefile.PL
>make
>make install
>
I'm trying to install the module on Red Hat 5.2 and the make install
step fails with the error message:
/bin/sh:
/var/tmp/perl-root/usr/lib/perl5/lib/i386-linux/5.00401/perllocal.pod:
No such file or directory
make:***[doc_site_install] Error 1
Any advice?
TIA,
Toby Poynder
------------------------------
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 5670
**************************************
