[12211] in Perl-Users-Digest
Perl-Users Digest, Issue: 5811 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri May 28 02:07:25 1999
Date: Thu, 27 May 99 23:01:25 -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 Thu, 27 May 1999 Volume: 8 Number: 5811
Today's topics:
Re: Perl "constructors" armchair@my-deja.com
Re: Perl "constructors" armchair@my-deja.com
Re: Perl "constructors" armchair@my-deja.com
Re: Perl and Oracle help! <cassell@mail.cor.epa.gov>
Re: perl script as an executable (Steve Vertigan)
Re: perl script as an executable <uri@sysarch.com>
Re: Strip "http" from URL's <otis@my-deja.com>
Re: Strip "http" from URL's (Larry Rosler)
Re: why doesn't my first program work?? (ok , third or (Ronald J Kimball)
Re: Writing a Form Validation Script (Charles R. Thompson)
Special: Digest Administrivia (Last modified: 12 Dec 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 28 May 1999 04:36:30 GMT
From: armchair@my-deja.com
Subject: Re: Perl "constructors"
Message-Id: <7il6ge$ruq$1@nnrp1.deja.com>
In article <7i3spi$u50$1@nnrp1.deja.com>,
John Porter <jdporter@min.net> wrote:
> In article <7i2to7$83g$1@nnrp1.deja.com>,
> armchair@my-dejanews.com wrote:
>
> > I never left C++. Unlike some, I have not yet fallen in love with a
> > programming language. But maybe you are right, Perl can only be
> > understood by geniuses, where as C++ is the language of the common
> man.
>
> ROFL. The real difference is, C++ is a low-level language, and
> Perl is a high-level language. Each has its strengths, and its
> peculiar idiom. Some aspects of Perl's idiom can seem bizarre to
> people who are used to C++ (not to mention toy languages like VB).
Since the looping and decision constructs of Perl are the same as C and
C++, and since C++ now has a string class, perhaps it is the dynamic
arrays and dynamic hashes that have you rolling on the floor and
laughing. Well, via the Standard Template Library (STL), those data
structures also exist in C++ as well (few, if any vendors are not
shipping the STL with their compiler). What then puts Perl at a higher
level than C++? Regular expressions? my @array = <FILE>; is nice, but
once you write similar routines in C++, you also have complete control
over the error handling.
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: Fri, 28 May 1999 05:04:56 GMT
From: armchair@my-deja.com
Subject: Re: Perl "constructors"
Message-Id: <7il85o$t0u$1@nnrp1.deja.com>
In article <7ibr2t$3qv$1@nnrp1.deja.com>,
John Porter <jdporter@min.net> wrote:
> In article <7i592o$t2m$1@nnrp1.deja.com>,
> armchair@my-dejanews.com wrote:
> > In article <7i3s4k$tmj$1@nnrp1.deja.com>,
> > John Porter <jdporter@min.net> wrote:
> > >...
> >
> > I guess I missed it. We know that we have a char *. It is
> > not a number
> > or string. You raise one highly unlikely scenario that I am very
> > surprised Russ Allberry hasn't jumped all over you about -
> > 1.) you say
> > that maybe the function is casting a x pointer to a char * before
> > returning it and your raise another point that is related to a
> > programming error in code - 2. maybe we have a char * that is not
> > pointing to a null-terminated character array. This and the
> > identical in principal "legal SGML" question has you making a
> > type of
> > "argument" that we see regarding legislation to outlaw
> > something such
> as
> > guns - show an example where the proposed restrictions/changes
> > would not
> > have been sufficient in a case - then try and make the
> > listener take a
> > bogus logical step to - "so restrictions/laws/requirements/changes
> > do not help AT ALL".
>
> I appreciate your trying to deal with me on this, but
> somehow we manage
> to continue to talk past each other.
>
> I barely understand what you're saying, above, and I have no idea
> whatsoever how it relates to what I said before.
Would you agree that you and I disagree on whether the forced type
declaration in C++ adds to the readability and understandability of the
code in languages such as Perl?
>
> > > Scalar* p = get_next();
> > >
> > > // Hmm. Maybe p points to a String, maybe to an Integer.
> >
> > But we know it points. It's not a number or string via
> > built-in types,
> > nor does it point to them.
>
> Variables in Perl (scalars, arrays, hashes) are, under the hood,
> pointers to data structures; but the language "sugar-coats" the use
> of these pointers. So your objection here is null. I was trying to
> show how Perl works using C++ syntax. I should perhaps have used
> references, rather than pointers, to make my point, since that is
> C++'s equivalent sugar-coating.
Scalar variables in Perl (numbers, strings, references to
(numbers,strings,hashes,arrays,objects)) are all identified the same.
my $variable.
This is not the same as C++ syntax. Nor is is that same as what takes
place under the hood.
>
> (Btw, p could indeed point to any type, including built-ins.
> Maybe not in an ideal system, but it's still possible, and common.)
No it can't. Try and get this to compile
int *a;
short b = 2;
a = &b;
Only pointers declared as void can point to any variable, and then you
can't dereference them unless you cast them to the appropriate pointer -
you must ultimately know they type of what they point to.
>
> > Here's a point you could/may be making: by looking at the code which
> > follows the declaration one can usually pick up the type. Such as
> >
> > my $p = $a->get_next();
> > $p++; # clearly number (we hope)
> >
> > my $p = $a->get_next();
> > my $z = $p . ".doc"; # gotta be a string (fingers crossed)
>
> Presumably both ++ and . can be overloaded, so both of those
> assumptions are probably premature.
Overloading of operators in Perl? I guess I missed that in perlobj.
> > I wasn't suggesting that you need to check the type of $a as in
> > " my $a = my_func(); "
> > in code. You can assume my_func() is giving you the right
> > thing - just
> > suggesting that explicit types makes a program easier to follow.
>
> The philosophy of OO says that types should be abstracted. Different
> systems abstract them to different levels, and perhaps the best we
> can say is that this is proper. In Perl, it was decided that -- most
> of the time -- numbers and strings should be dealt with via a common
> abstraction, i.e. a common superclass.
If I have a date/time object, the "philosophy of OO" may say that I
don't need to know how it is represented, but they have nothing against
me knowing that it represents dates and times. But with my $a =
somefunction(); I don't know whether $a represents date/times or is a
count of the number of times some functionality in Perl is represented
as having arose from long and deep thought.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: Fri, 28 May 1999 05:29:08 GMT
From: armchair@my-deja.com
Subject: Re: Perl "constructors"
Message-Id: <7il9j3$u1r$1@nnrp1.deja.com>
In article <7ibrqa$4br$1@nnrp1.deja.com>,
John Porter <jdporter@min.net> wrote:
> In article <7i5b2g$u8n$1@nnrp1.deja.com>,
> armchair@my-dejanews.com wrote:
> > The fact that [the variable] represents temperature should be
> > reflected in the variable name, and the ranges/units should be given
> > with a comment in Perl or C++. Can't disagree with that at
> > all. But if
> > type declaration doesn't tell me everything, does it tell
> > me nothing?
>
> Perhaps the fact that the value is to be used as a number, or was
> originally a number, can also simply be reflected in the
> variable name.
>
> Or perhaps the only thing you need your "type declaration" to tell you
> is that the value is scalar in dimension.
Since Perl scalars now hold references, which can point to any data
sructure or object in the system, you will never know that now. In Perl
4, yes, you would say "my $a = somfunc(); - that has a scalar
dimension". No longer.
>
> > int a = object.GetHooziwhatzit(); // C++
> >
> > my $a = $object->GetHooziwhatzit(); # Perl
> >
> > The C++ programmer does not know the range of a Hooziwhatzit,
> > nor the
> > real world phenomenem it is representing, unless given comments/good
> > variable names, but they do know at declaration how it
> > is represented
> > (code reader is not the original programmer).
> >
> > The Perl programmer (code reader) still wonders - in addition
> > to what
> > the C++ programmer ponders above - is a Hooziwhatzit represented
> > by an
> > object, string or number? Maybe it doesn't matter, maybe it probably
> > doesn't matter,
>
> Maybe it *shouldn't* matter, and the only reason anyone ever thinks
> it "does" matter is because they're used to having to explicitly
> write and read such declarations.
>
> What you'll find in Perl is what the rest of us have found: it's one
> less thing to have to worry about, one less thing to have to think
> about. But as I said before, if you're writing numerical analysis
> routines -- FFT, matrix math, etc. -- there are better choices than
> Perl.
What if I am just doing object oriented programming of a general nature?
Or is Perl just suited for text processing?
>
> > ...maybe the Perl programmer always comments and gives good
> > variable names that reflect the type, but it certainly doesn't make
> the
> > code _easier_ to read.
>
> "Ease of reading" is a famous chimera, especially in this newsgroup.
> I contend that a sentence with *fewer* semantic tokens is easier to
> read, vs. one with more.
>
> The big dog bit me.
>
> vs.
>
> The dog bit me.
>
> Hmm. Which is "easier to read"?
That's a valid point that the datatype may be unnecessary
information at times that could give extra input to an already burdened
reader. But in your sentence above, me would be the variable
declaration, so in Perl terms it would be:
The dog bit.
You (and another poster) are saying that me is irrelevant since we know
it is something that got bit and even if we know it's me, we don't know
how old me is, or what me is wearing, or even if me is dressed
properly, so knowing that it's me is worthless.
>
> > In Perl I would be tempted to always write
> >
> > my $a = $object->GetHooziwhatzitNumber(); #or
> > my $a = $object->GetHooziwhatzitString(); # or
> > my $a = $object->GetHooziwhatzitObject(); # depending
> > on Hooziwhatzit
> >...
>
> Tempted, that is, until you learned to actually write Perl in Perl,
> rather than writing C++ in Perl.
Always remember the Perl motto: "There's more than one way to do it -
TMTOWTDI". With a motto like that, you would think that there would be
a great acceptance of all the diversity of code stylings. Every color of
variable naming, all code structuring religions, and every crede of
oject definition.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: Thu, 27 May 1999 20:34:40 -0700
From: David Cassell <cassell@mail.cor.epa.gov>
Subject: Re: Perl and Oracle help!
Message-Id: <374E0ED0.7E0FC2B0@mail.cor.epa.gov>
Raimi wrote:
>
> On Thu, 27 May 1999 jknoll@my-deja.com wrote:
>
> Hello!
>
> > Does perl work seemlessly with Oracle databases? Is it decently fast
> > and efficient?
>
> It works. The DBD::Oracle thing works fine.
> But it is by no means fast and efficient (the Database). The overhead
> perl adds to the Database accesses is neglectable but the engine itself
> is REALLY slow. (Well, it does not get any slowser when databases grow or
> when statements get more complex...)
>
> Don't start using Oracle below a PII 400 Mhz and 256 MB RAM.
And even that won't solve your problem. No matter what language
you use, Oracle is somewhat, umm, casual about getting around to
completing that connection.
Perl is quite efficient. Take a look at DBI and DBD::* modules.
But as far as fast, you will want to look into ways to maintain
a connection to your database, or you'll take a lot of performance
hits.
HTH,
David
--
David Cassell, OAO cassell@mail.cor.epa.gov
Senior computing specialist
mathematical statistician
------------------------------
Date: Fri, 28 May 1999 05:32:49 GMT
From: vertigan@bigfoot.com (Steve Vertigan)
Subject: Re: perl script as an executable
Message-Id: <374e2971.91109889@news.aurum.net.au>
Tom Christiansen <tchrist@mox.perl.com> wrote thus:
> [courtesy cc of this posting mailed to cited author]
>
>In comp.lang.perl.misc, therzog@knotech.com (Tim Herzog) writes:
>: read STDIN, $_, $ENV{'CONTENT_LENGTH'};
>
>That code is evil and wrong. You are, in effect, recreating
>a broken wheel.
Could someone tell me why this is evil and wrong? I've been using a
parse_form routine derived from this for a while now and haven't had
problems to my knowledge. If possible I would rather just fix my code than
using a module as it's part of a larger library I've grown accustomed to
using.
Regards,
--Steve
------------------------------
Date: 28 May 1999 01:54:04 -0400
From: Uri Guttman <uri@sysarch.com>
Subject: Re: perl script as an executable
Message-Id: <x7emk1kadf.fsf@home.sysarch.com>
>>>>> "SV" == Steve Vertigan <vertigan@bigfoot.com> writes:
SV> Tom Christiansen <tchrist@mox.perl.com> wrote thus:
>> [courtesy cc of this posting mailed to cited author]
>>
>> In comp.lang.perl.misc, therzog@knotech.com (Tim Herzog) writes:
>> : read STDIN, $_, $ENV{'CONTENT_LENGTH'};
>>
>> That code is evil and wrong. You are, in effect, recreating
>> a broken wheel.
SV> Could someone tell me why this is evil and wrong? I've been using
SV> a parse_form routine derived from this for a while now and haven't
SV> had problems to my knowledge. If possible I would rather just fix
SV> my code than using a module as it's part of a larger library I've
SV> grown accustomed to using.
take a look at CGI.pm and see how it handles it. or CGI::Lite.pm. both
are known to be very stable and reliable. then you will see some of the
problems with your code.
and here are a few random comments on one line of code shown above:
did you check if it is a GET? can you handle GET or POST equally well?
did you check the return value from read to see if you read all the
POSTed data?
there are dozens of other advantages to use CGI.pm. the whole point is
that it has been done before and better than most of us could ever
emulate. so unless you know what you are doing (which eliminates 99% of
us), and you need ultimate speed or simplicity, then rolling your own
cgi code is a waste of time and effort.
CGI.pm allows you to test the programs from a command line. it can make
errors display cleanly in html. it can handle data persistance across
forms.
can any hand-rolled cgi package do all those useful things? so why waste
your time. the actual code needed to use CGI.pm is less than the broken
code you cut and paste in now.
uri
--
Uri Guttman ----------------- SYStems ARCHitecture and Software Engineering
uri@sysarch.com --------------------------- Perl, Internet, UNIX Consulting
Have Perl, Will Travel ----------------------------- http://www.sysarch.com
The Best Search Engine on the Net ------------- http://www.northernlight.com
------------------------------
Date: Fri, 28 May 1999 02:55:12 GMT
From: Otis Gospodnetic <otis@my-deja.com>
Subject: Re: Strip "http" from URL's
Message-Id: <7il0if$o1p$1@nnrp1.deja.com>
In article <7iktqv$m8u$1@nnrp1.deja.com>,
wired2000@my-deja.com wrote:
> Hi,
>
> I've been trying to figure out a substitution string that will do the
> following:
>
> Given any URL such as:
> http://www.whatever.com/whatever/ or
> http://www.whatever.com/whatever or
> http://whatever.com/whatever/ or
> http://www.whatever.com/whatever/whatever.xxx or
> http://www.whatever.com/
>
> Will strip away everything after the actual website, so the output of
> the above examples would be:
>
> /whatever/
> /whatever
> /whatever/
> /whatever/whatever.xxx
> /
Maybe something like this:
use URI;
$u1 = URI->new("http://www.perl.com/whatever/");
$scheme = $u->scheme;
$opaque = $u->opaque;
$path = $u->path; # try printing this
$frag = $u->fragment;
Otis
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: Thu, 27 May 1999 21:16:07 -0700
From: lr@hpl.hp.com (Larry Rosler)
Subject: Re: Strip "http" from URL's
Message-Id: <MPG.11b7b84358b13469989b1b@nntp.hpl.hp.com>
In article <7il0if$o1p$1@nnrp1.deja.com> on Fri, 28 May 1999 02:55:12
GMT, Otis Gospodnetic <otis@my-deja.com> says...
+ In article <7iktqv$m8u$1@nnrp1.deja.com>,
+ wired2000@my-deja.com wrote:
...
+ > Given any URL such as:
+ > http://www.whatever.com/whatever/ or
+ > http://www.whatever.com/whatever or
+ > http://whatever.com/whatever/ or
+ > http://www.whatever.com/whatever/whatever.xxx or
+ > http://www.whatever.com/
+ >
+ > Will strip away everything after the actual website, so the output
+ > of the above examples would be:
+ >
+ > /whatever/
+ > /whatever
+ > /whatever/
+ > /whatever/whatever.xxx
+ > /
+
+ Maybe something like this:
+
+ use URI;
+ $u1 = URI->new("http://www.perl.com/whatever/");
+ $scheme = $u->scheme;
+ $opaque = $u->opaque;
+ $path = $u->path; # try printing this
+ $frag = $u->fragment;
Good Lord. A new disease -- modulitis.
s%^http://[^/]+%%;
--
(Just Another Larry) Rosler
Hewlett-Packard Company
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: Thu, 27 May 1999 23:39:26 -0400
From: rjk@linguist.dartmouth.edu (Ronald J Kimball)
Subject: Re: why doesn't my first program work?? (ok , third or something)
Message-Id: <1dshle8.l7o0qw24m0j9N@p122.tc8.metro.ma.tiac.com>
Bastiaan S van den Berg <office@asc.nl> wrote:
> first , i use .cgi extensions because my webserver can't run .pl scripts for
> some weird reason..
Note that when you load in a file with require, you should still be able
to use the .pl suffix. It's just the main program that your webserver
is running, and that will need to have the .cgi suffix.
--
_ / ' _ / - aka -
( /)//)//)(//)/( Ronald J Kimball rjk@linguist.dartmouth.edu
/ http://www.tiac.net/users/chipmunk/
"It's funny 'cause it's true ... and vice versa."
------------------------------
Date: Fri, 28 May 1999 05:53:44 GMT
From: design@raincloud-studios.com (Charles R. Thompson)
Subject: Re: Writing a Form Validation Script
Message-Id: <MPG.11b7fad0ef1b55f79896d4@news>
In article <7ijtni$ufr$1@nnrp1.deja.com>, Bhaskar Thiagarajan says...
> If you did a simple search on the topic you'll get a whole bunch of
> sites...anyways...try this one called Matt's script archive..well
> documented scripts.
> http://www.worldwidemart.com/scripts/
I really wish people would quit doing that. It just adds to the useless
code samples floating around the net.
CT
------------------------------
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 5811
**************************************
