Extropia

[Don Stefani]

I was looking at extropia.com and after googling groups for awhile it appears that their
software underwent major upgrades around 2001. I was looking for examples of medium size
applications that I can learn from.

From glancing at the code of the 'address_book.cgi' script it seems to meet the criteria
for decent Perl coding (As far as I could tell, that's why I'm posting here).
I have a bit of code as text posted here:
http://www.techcraft.us/address_book.html

From looking at this, what do you folks think?
I know from what I've read that they became outdated and knew they had to rebuild their
stuff. This doesn't look like 'Matts Script Archive' stuff to me.

As always thanks for your opinions.

dstefani

 

[Tassilo v. Parseval]

Also sprach Don Stefani:

I was looking at extropia.com and after googling groups for awhile it appears that their
software underwent major upgrades around 2001. I was looking for examples of medium size
applications that I can learn from.

From glancing at the code of the 'address_book.cgi' script it seems to meet the criteria
for decent Perl coding (As far as I could tell, that's why I'm posting here).
I have a bit of code as text posted here:
http://www.techcraft.us/address_book.html

From looking at this, what do you folks think?
I know from what I've read that they became outdated and knew they had to rebuild their
stuff. This doesn't look like 'Matts Script Archive' stuff to me.

As always thanks for your opinions.

dstefani

Tassilo

 

[Tassilo v. Parseval]

Also sprach Don Stefani:

I was looking at extropia.com and after googling groups for awhile it appears that their
software underwent major upgrades around 2001. I was looking for examples of medium size
applications that I can learn from.

From glancing at the code of the 'address_book.cgi' script it seems to meet the criteria
for decent Perl coding (As far as I could tell, that's why I'm posting here).
I have a bit of code as text posted here:
http://www.techcraft.us/address_book.html

From looking at this, what do you folks think?

It's a somewhat unusual application. It seems to contain hundreds of
variables but hardly any programming logic. The logic appears to be
hidden in the Extropia:: modules (which we can't see).

The script uses tainting, strictures, warnings and CGI.pm which is a
good sign. Furthermore, the code is formatted and indented nicely enough
to make it trustworthy.

There are minor things I don't instantly understand about it, though.
For example at the top of the file:

BEGIN{
use vars qw(@dirs);
@dirs = qw(Modules
Modules/CPAN .);
}
use lib @dirs;
unshift @INC, @dirs unless $INC[0] eq
$dirs[0];

The unshift() happens "too late" for the various use() statements later
on. But maybe one of the modules does a require() in one of its
subroutines in which case the above could make sense and be correct.

I know from what I've read that they became outdated and knew they had to rebuild their
stuff. This doesn't look like 'Matts Script Archive' stuff to me.

Yes, doesn't look like it at all. This script was written almost
certainly by someone with a good amount of experience with Perl.

Tassilo

 

[David K. Wall]

Also sprach Don Stefani:

It's a somewhat unusual application. It seems to contain hundreds of
variables but hardly any programming logic. The logic appears to be
hidden in the Extropia:: modules (which we can't see).

The script uses tainting, strictures, warnings and CGI.pm which is a
good sign. Furthermore, the code is formatted and indented nicely enough
to make it trustworthy.

There are minor things I don't instantly understand about it, though.

[snip]

I don't understand the reason for some of the arrays. For example,

my @SESSION_CONFIG_PARAMS = (
-TYPE => 'File',
-MAX_MODIFY_TIME => 60 * 60,
-SESSION_DIR => "$GLOBAL_DATAFILES_DIRECTORY/Sessions",
-FATAL_TIMEOUT => 0,
-FATAL_SESSION_NOT_FOUND => 0
);


It's an array, but the data looks as if it should be in a hash. The only
thing I can think of is that it's being passed to a subroutine and used to
initialize a hash in the sub. But if that's so, why not initialize it as
a hash from the start, and then just pass a hash reference to the
subroutine?

 

[Uri Guttman]

DKW> I don't understand the reason for some of the arrays. For example,

DKW> my @SESSION_CONFIG_PARAMS = (
DKW> -TYPE => 'File',
DKW> -MAX_MODIFY_TIME => 60 * 60,
DKW> -SESSION_DIR => "$GLOBAL_DATAFILES_DIRECTORY/Sessions",
DKW> -FATAL_TIMEOUT => 0,
DKW> -FATAL_SESSION_NOT_FOUND => 0
DKW> );


DKW> It's an array, but the data looks as if it should be in a
DKW> hash. The only thing I can think of is that it's being passed to
DKW> a subroutine and used to initialize a hash in the sub. But if
DKW> that's so, why not initialize it as a hash from the start, and
DKW> then just pass a hash reference to the subroutine?


i saw that too. i bet the sub's api is to take a list of args and
assign it to a hash. storing this in a hash and passing it whole would
work too but be slower. the hash has to be built and then listed in the
call. an array is faster in both cases. now if the api allowed a hash
ref OR a list, then the hash ref style would be faster. this is just a
case of an anal api designer who stuck with one method and that's that.

but i find all those predefined lists to be ugly. they seem to be
packaged args for standard calls. since i don't know the api or the
functional specs, i won't conjecture a better api. but when i see this
kind of anal text it is usually a warning that the coder knows enough to
do that style well but not enough to not to have to do it that way at
all.

uri

 

[Tassilo v. Parseval]

Also sprach Uri Guttman:

DKW> I don't understand the reason for some of the arrays. For example,

DKW> my @SESSION_CONFIG_PARAMS = (
DKW> -TYPE => 'File',
DKW> -MAX_MODIFY_TIME => 60 * 60,
DKW> -SESSION_DIR => "$GLOBAL_DATAFILES_DIRECTORY/Sessions",
DKW> -FATAL_TIMEOUT => 0,
DKW> -FATAL_SESSION_NOT_FOUND => 0
DKW> );


DKW> It's an array, but the data looks as if it should be in a
DKW> hash. The only thing I can think of is that it's being passed to
DKW> a subroutine and used to initialize a hash in the sub. But if
DKW> that's so, why not initialize it as a hash from the start, and
DKW> then just pass a hash reference to the subroutine?


i saw that too. i bet the sub's api is to take a list of args and
assign it to a hash. storing this in a hash and passing it whole would
work too but be slower. the hash has to be built and then listed in the
call. an array is faster in both cases. now if the api allowed a hash
ref OR a list, then the hash ref style would be faster. this is just a
case of an anal api designer who stuck with one method and that's that.

There might be another reason for that. A Perl array is more generic
than a Perl hash in that an array has an order that is for ever
destroyed once you turn it into a hash. Usually, when having data
organized as key/value pairs, order should not matter, but who knows?
For example this:

my @ADD_EVENT_MAIL_SEND_PARAMS = (
-FROM => '(e-mail address removed)',
-TO => '(e-mail address removed)',
-REPLY_TO => '(e-mail address removed)',
-SUBJECT => 'Address Book Addition'
);

If the above was used to create a mail-header, the fields could come out
as

From: ...
To: ...
Reply-To: ...
Subject: ...

Sure, the order doesn't even matter for mail-header fields but for the
sake of esthetics being allowed to specify it can be nice and considered
a feature.

but i find all those predefined lists to be ugly. they seem to be
packaged args for standard calls. since i don't know the api or the
functional specs, i won't conjecture a better api. but when i see this
kind of anal text it is usually a warning that the coder knows enough to
do that style well but not enough to not to have to do it that way at
all.

I would not instantly agree here. When I said this was an "unusual
application" I meant that it is more like an executable config file. A
bit like XUL maybe, the XML dialect to create user interfaces (used by
Mozilla, for instance).

I don't like those libraries a lot that only let the programmer specify
thousands of options and then doing all the work triggered by one
API-call based on those given options. But at least it's a deliberate
decision by those who design an API.

Tassilo