[32865] in Perl-Users-Digest
Perl-Users Digest, Issue: 4133 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Feb 8 18:09:35 2014
Date: Sat, 8 Feb 2014 15:09:03 -0800 (PST)
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, 8 Feb 2014 Volume: 11 Number: 4133
Today's topics:
Re: HTTP::Status <hjp-usenet3@hjp.at>
Re: Initialising a hash <ben@morrow.me.uk>
Re: Initialising a hash <rweikusat@mobileactivedefense.com>
Re: Initialising a hash <jimsgibson@gmail.com>
Re: Initialising a hash <ben@morrow.me.uk>
Re: Initialising a hash <rweikusat@mobileactivedefense.com>
Re: Initialising a hash <kkeller-usenet@wombat.san-francisco.ca.us>
Re: Initialising a hash <janek_schleicher@yahoo.de>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 6 Feb 2014 22:50:10 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: HTTP::Status
Message-Id: <slrnlf80si.m63.hjp-usenet3@hrunkner.hjp.at>
On 2014-02-06 18:58, Dave Saville <dave@invalid.invalid> wrote:
> On Thu, 6 Feb 2014 17:58:15 UTC, "Peter J. Holzer"
><hjp-usenet3@hjp.at> wrote:
>> On 2014-02-06 13:20, Dave Saville <dave@invalid.invalid> wrote:
>> > I thought what it did was setup subroutine(s) that take no paramteters
>> > and return the code number.
>>
>> This works for me:
[...]
>> use HTTP::Status qw(:constants);
>>
>> say HTTP_FOUND;
[...]
>
> Not on 5.8.2 :-)
Probably less a question of your Perl version as that of HTTP-Message.
On my workstation I have 6.03, on a server with Perl 5.8.0 I have 1.28,
which indeed doesn't export the :constants bundle. You could probably
upgrade HTTP-Message, though that might depend on some newer Perl
version.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Thu, 6 Feb 2014 22:21:34 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Initialising a hash
Message-Id: <egedsa-ek1.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>
> "Someone else wrote it and I know how to get it for free!" may also be a
> sensible approach, but only [BLAH BLAH NIH BLAH]
Oh, do shut up.
Ben
------------------------------
Date: Thu, 06 Feb 2014 23:16:09 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Initialising a hash
Message-Id: <87vbwrbznq.fsf@sable.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>>
>> "Someone else wrote it and I know how to get it for free!" may also be a
>> sensible approach, but only [BLAH BLAH NIH BLAH]
>
> Oh, do shut up.
This is a design question: How should 'small, mostly static key/ value
database which occasionally need to be changed be stored and
accessed?'. The obvious choices would be
- store them in a text file in some "program-independent"
format, similar to existing database of this kind, eg,
services or protocols
- put the database directly into the code in a suitable way
Link with a third-party module which has a more-or-less up-to-date and
more-or-less maintained or unmaintained list internally hard-coded into
it and provides a more-or-less cumbersome and inefficient interface for
accessing it seems to be a singularly 'efficient' way to combine the
drawbacks of both approaches without providing the advantages of either
and "But someone else wrote that!" is not really a reason to use the
internally hard-coded list in this way: It can be transformed into a real
database file easily or alternatively, it can be put directly into the
code via copy'n'paste, thus yiedling either "can be maintained with
regard for the code using it, could use different versions on different
occasions (eg, a localized map), can be used by any kind of code" or
"everything together in a single file which can be edited easily".
I'd gladly listen to a more rational argument in favour of using the
'module with hard-coded list in it' than "It already exists".
------------------------------
Date: Fri, 07 Feb 2014 09:59:57 -0800
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: Initialising a hash
Message-Id: <070220140959577205%jimsgibson@gmail.com>
In article <87vbwrbznq.fsf@sable.mobileactivedefense.com>, Rainer
Weikusat <rweikusat@mobileactivedefense.com> wrote:
> This is a design question: How should 'small, mostly static key/ value
> database which occasionally need to be changed be stored and
> accessed?'. The obvious choices would be
>
> - store them in a text file in some "program-independent"
> format, similar to existing database of this kind, eg,
> services or protocols
>
> - put the database directly into the code in a suitable way
>
> Link with a third-party module which has a more-or-less up-to-date and
> more-or-less maintained or unmaintained list internally hard-coded into
> it and provides a more-or-less cumbersome and inefficient interface for
> accessing it seems to be a singularly 'efficient' way to combine the
> drawbacks of both approaches without providing the advantages of either
> and "But someone else wrote that!" is not really a reason to use the
> internally hard-coded list in this way: It can be transformed into a real
> database file easily or alternatively, it can be put directly into the
> code via copy'n'paste, thus yiedling either "can be maintained with
> regard for the code using it, could use different versions on different
> occasions (eg, a localized map), can be used by any kind of code" or
> "everything together in a single file which can be edited easily".
>
> I'd gladly listen to a more rational argument in favour of using the
> 'module with hard-coded list in it' than "It already exists".
The reasons to use HTTP::Status instead writing your own include, but
are not limited to, the following:
1. It already exists, so I won't have to waste my time re-writing it,
and I can get on with the actual problem I am trying to solve.
2. Somebody else wrote it, and they are probably a better programmer
than I and more knowledgable about HTTP status codes.
3. The module is complete and I won't have to worry about tracking down
every possible status code or searching down the relevant RFCs.
4. The CPAN module comes with documentation built-in.
5. The CPAN module comes with test code to ensure it has been installed
correctly. These tests are performed automatically when I install the
module, and can be rerun at any time very easily. Tests are performed
automatically on any module that is submitted to CPAN, and on platforms
for which I do not have access.
6. Documentation is available on the web.
7. I only have to put one line in my program to use it.
8. Lots of people use the module, so there is a good chance that any
bugs will be fixed. (That is certainly not true for the programs I
write, for which I am usually the only user.)
9. If the module does need maintenance, there is a good chance the
module author will do it.
10. HTTP status codes haven't changed in a long time, and probably
won't change in a non-compatible manner (e.g., more codes may be added,
but the current codes are not likely to change.)
Your aversion to using CPAN modules is well-known to readers of this
news group. I do not share that opinion, and your constant harping
against third party software becomes a little tiresome. Maybe you could
just limit yourself to critiquing the specifics of individual modules
instead of making blanket statements against all of them.
Lots of people have put in a lot of time and energy providing CPAN
modules. I even wrote a couple myself, and any reports of bugs in those
would immediately spur me into action to try to fix them. I suspect
most CPAN module authors would feel the same.
Of course, there are no doubt bad CPAN modules, and lots that have been
abandoned by their authors. It is alway a problem separating the wheat
from the chaff. Discussion on Usenet is one way to discover good
modules and bad ones. Generalization that any use of third-party
modules is bad serves no purpose.
Thank you for your many positive contributions to this group. You are
obviously very knowledgable about Perl.
--
Jim Gibson
------------------------------
Date: Fri, 7 Feb 2014 19:35:04 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Initialising a hash
Message-Id: <84pfsa-khe.ln1@anubis.morrow.me.uk>
Quoth Jim Gibson <jimsgibson@gmail.com>:
>
> 5. The CPAN module comes with test code to ensure it has been installed
> correctly. These tests are performed automatically when I install the
> module, and can be rerun at any time very easily.
This, unfortunately, is not true. There is some ongoing work to install
tests when a distribution is installed and provide utilities to rerun
tests against an installed distribution, but it doesn't usually happen
yet. One reason for this is that a lot of Perl test suites assume they
will be running in the distribution's build directory, and rely on data
files and such that don't end up being installed.
Ben
------------------------------
Date: Fri, 07 Feb 2014 20:47:33 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Initialising a hash
Message-Id: <87d2iy7iqi.fsf@sable.mobileactivedefense.com>
Jim Gibson <jimsgibson@gmail.com> writes:
> In article <87vbwrbznq.fsf@sable.mobileactivedefense.com>, Rainer
> Weikusat <rweikusat@mobileactivedefense.com> wrote:
>
>> This is a design question: How should 'small, mostly static key/ value
>> database which occasionally need to be changed be stored and
>> accessed?'. The obvious choices would be
>>
>> - store them in a text file in some "program-independent"
>> format, similar to existing database of this kind, eg,
>> services or protocols
>>
>> - put the database directly into the code in a suitable way
>>
>> Link with a third-party module which has a more-or-less up-to-date and
>> more-or-less maintained or unmaintained list internally hard-coded into
>> it and provides a more-or-less cumbersome and inefficient interface for
>> accessing it seems to be a singularly 'efficient' way to combine the
>> drawbacks of both approaches without providing the advantages of either
>> and "But someone else wrote that!" is not really a reason to use the
>> internally hard-coded list in this way: It can be transformed into a real
>> database file easily or alternatively, it can be put directly into the
>> code via copy'n'paste, thus yiedling either "can be maintained with
>> regard for the code using it, could use different versions on different
>> occasions (eg, a localized map), can be used by any kind of code" or
>> "everything together in a single file which can be edited easily".
>>
>> I'd gladly listen to a more rational argument in favour of using the
>> 'module with hard-coded list in it' than "It already exists".
>
> The reasons to use HTTP::Status instead writing your own include, but
> are not limited to, the following:
>
> 1. It already exists, so I won't have to waste my time re-writing it,
> and I can get on with the actual problem I am trying to solve.
Not applicable since HTTP::Status is just window dressing on top of an
otherwise inaccessible hash table. The hash table can be put into 'other
code' via copy'n'paste which makes using it less work than going through
the procedural interface.
> 2. Somebody else wrote it, and they are probably a better programmer
> than I and more knowledgable about HTTP status codes.
The 'bulk' of HTTP::Status is
sub status_message ($) { $StatusCode{$_[0]}; }
according to a clpm chestnut, this is bad because it means passing an
array to status_message will result in the array size being interpreted
as status code instead of the first element of the array (this is also
undocumented). Hash lookups in Perl aren't exactly rocket science, so
your statement doesn't really seem to be applicable here, either.
> 3. The module is complete and I won't have to worry about tracking down
> every possible status code or searching down the relevant RFCs.
Not applicable since you can use the table the module contains, as I've
already written a couple of times. Also, that you're willing to believe
that the table is complete doesn't mean it actually is so and there's
still related problem of how to update it in case this becomes
necessary.
> 4. The CPAN module comes with documentation built-in.
If you aren't using the module, you won't need its documentation.
> 5. The CPAN module comes with test code to ensure it has been installed
> correctly. These tests are performed automatically when I install the
> module, and can be rerun at any time very easily. Tests are performed
> automatically on any module that is submitted to CPAN, and on platforms
> for which I do not have access.
There's nothing to test here, since we're still talking about a hash
lookup.
> 6. Documentation is available on the web.
See above.
> 7. I only have to put one line in my program to use it.
This is wrong on two accounts:
1. You are 'putting' all the lines contained in the module in your
program, you just don't have to write them.
2. You still need to call the function which does the hash lookup for
you everytime you want to use it.
> 8. Lots of people use the module, so there is a good chance that any
> bugs will be fixed. (That is certainly not true for the programs I
> write, for which I am usually the only user.)
Not applicable in this case.
> 9. If the module does need maintenance, there is a good chance the
> module author will do it.
Unsubstantiated belief. According to my experience, this is also usually
wrong: If the code is found lacking, chances are that this is the case
because you're using it in a way the author doesn't which means you get
to fix it yourself (not that I'd mind doing that -- if the issue affects
me, I'm naturally in the position to do something about it).
> 10. HTTP status codes haven't changed in a long time, and probably
> won't change in a non-compatible manner (e.g., more codes may be added,
> but the current codes are not likely to change.)
I have no idea what this is supposed to express here.
> Your aversion to using CPAN modules is well-known to readers of this
> news group. I do not share that opinion, and your constant harping
> against third party software becomes a little tiresome. Maybe you could
> just limit yourself to critiquing the specifics of individual modules
> instead of making blanket statements against all of them.
This is a statement about me and not about the module in question. It is
also a wrong statement as I was criticizing a specific module and have
praised other modules in the past, eg, most-recently, File::Temp.
> Lots of people have put in a lot of time and energy providing CPAN
> modules.
Lost of people have put a lot of time and energy into all kinds of tasks
such as 'building a perpetuum mobile' or 'making gold out of lesser
materials'.
[...]
> Of course, there are no doubt bad CPAN modules, and lots that have been
> abandoned by their authors. It is alway a problem separating the wheat
> from the chaff. Discussion on Usenet is one way to discover good
> modules and bad ones. Generalization that any use of third-party
> modules is bad serves no purpose.
I usually have the exact opposite impression: It is assumed than
"downloading something from the internet" would be a worthy end in
itself, IOW, anything someone else wrote and published on the web is
prima facie better than anything not published on the web. This is
illogical, not the least because "putting something on CPAN" comes with
a considerable, bureaucratic/ administrative overhead and not everyone
has so much spare time available and even if he has it, he might not
care that much about "getting his name printed on the web". It doesn't
follow that all these people are "inferior programmers" because they
don't want to spend time on this (and vice versa).
I'd rather advocate making intelligent choices here based on a default]
policy of "if in doubt, don't use it": Make sure that you get the cream
but stay clear of everything which is just 'average'/ mediocre.
------------------------------
Date: Fri, 7 Feb 2014 21:16:28 -0800
From: Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us>
Subject: Re: Initialising a hash
Message-Id: <c6rgsax9nh.ln2@goaway.wombat.san-francisco.ca.us>
On 2014-02-07, Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>
> The 'bulk' of HTTP::Status is
>
> sub status_message ($) { $StatusCode{$_[0]}; }
>
> according to a clpm chestnut, this is bad because it means passing an
> array to status_message will result in the array size being interpreted
> as status code instead of the first element of the array (this is also
> undocumented).
[snip]
> I'd rather advocate making intelligent choices
Clearly not, since the "intelligent choice" would be to submit a patch,
not write your own code from scratch.
--keith
--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information
------------------------------
Date: Sat, 08 Feb 2014 07:05:03 +0100
From: Janek Schleicher <janek_schleicher@yahoo.de>
Subject: Re: Initialising a hash
Message-Id: <bllvoiFfcocU1@mid.individual.net>
Am 07.02.2014 21:47, schrieb Rainer Weikusat:
> Not applicable since HTTP::Status is just window dressing on top of an
> otherwise inaccessible hash table. The hash table can be put into 'other
> code' via copy'n'paste which makes using it less work than going through
> the procedural interface.
Even copy+paste means more work than just using HTTP::Status.
It's not like you try to get Angular.js to run.
> The 'bulk' of HTTP::Status is
>
> sub status_message ($) { $StatusCode{$_[0]}; }
ok, that's still shorter than any hand written code and much easier to
maintain.
> according to a clpm chestnut, this is bad because it means passing an
> array to status_message will
a method call status_message
is very unlikely to get called in list contet
> result in the array size being interpreted
> as status code instead of the first element of the array (this is also
> undocumented). Hash lookups in Perl aren't exactly rocket science, so
> your statement doesn't really seem to be applicable here, either.
Well, HTTP::Status doesn't claim to be rocket science, it solves one
little problem, but it solves ist.
> Not applicable since you can use the table the module contains, as I've
> already written a couple of times.
You can use it of course.
But do you update it also?
And even if you use it, it's still more time, more work and less
maintainable than to use this module direct.
> Also, that you're willing to believe
> that the table is complete doesn't mean it actually is so and there's
> still related problem of how to update it in case this becomes
> necessary.
Copy+Paste makes it even worse
> If you aren't using the module, you won't need its documentation.
So you have to write your own documentation.
Come on, it's past 1975, an undocumented, untested part of our code is a
bug, nor a feature.
> There's nothing to test here, since we're still talking about a hash
> lookup.
It still has to work.
Even when installed in customers environment or whereever.
Again, 1975 is over.
>
>> 7. I only have to put one line in my program to use it.
>
> This is wrong on two accounts:
>
> 1. You are 'putting' all the lines contained in the module in your
> program, you just don't have to write them.
So, it's better if you copy+paste them??
> 2. You still need to call the function which does the hash lookup for
> you everytime you want to use it.
What's the problem.
If you want, you can add any Memorize-ic function to avoid it.
>> 8. Lots of people use the module, so there is a good chance that any
>> bugs will be fixed. (That is certainly not true for the programs I
>> write, for which I am usually the only user.)
>
> Not applicable in this case.
That's very applicable.
>> 9. If the module does need maintenance, there is a good chance the
>> module author will do it.
>
> Unsubstantiated belief.
Why?
> According to my experience, this is also usually
> wrong: If the code is found lacking, chances are that this is the case
> because you're using it in a way the author doesn't which means you get
> to fix it yourself (not that I'd mind doing that -- if the issue affects
> me, I'm naturally in the position to do something about it).
O.K., so you copy+pastied it,
what is better than?
> This is a statement about me and not about the module in question. It is
> also a wrong statement as I was criticizing a specific module and have
> praised other modules in the past, eg, most-recently, File::Temp.
File::Temp is a module usually distributed,
it's part of perldoc.
Wow, you are using standard installed modules.
> Lost of people have put a lot of time and energy into all kinds of tasks
> such as 'building a perpetuum mobile' or 'making gold out of lesser
> materials'.
HTTP::Status works and does what it claims.
Year, people tried to build perpetuum mobile, well, they nether worked
and aren't part of CPAN IIRC.
> I usually have the exact opposite impression: It is assumed than
> "downloading something from the internet" would be a worthy end in
> itself, IOW, anything someone else wrote and published on the web is
> prima facie better than anything not published on the web.
Nobody said that,
but most of the time it's worth to use it,
and often it's at least better than to reinvent it,
for at least at the first days,
and only some problems are worth it to invest a manweek+ just because we
are paronoid about internet solutions.
Also, explain me, why copy+paste is superior than to just use what you
intend to c+p?
> This is
> illogical, not the least because "putting something on CPAN" comes with
> a considerable, bureaucratic/ administrative overhead and not everyone
> has so much spare time available and even if he has it ...
So, you have all this overhead available?
Lucky guy!
Be glad in 1975.
Greetings,
Janeks
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 V11 Issue 4133
***************************************
