in reply to (jeffa) Re: Code review and question for parts script
in thread Code review and question for parts script

Thanks for your review, I was wondering about that kludge on 419. Unfortunately, this is on a hosted system, so I don't have access to Text::CSV or Text::CSV_XS (which is a pre-req for DBD::CSV). I will make a request to see if I can get those modules installed. I should have mentioned that in my first post...

Same goes for Class::DBI, although I hadn't thought of using it. It looks pretty slick, so even if I don't get it installed on the hosted system, I will install it on my system and play around with it.

When I declare a global variable is it like this?: 

use vars qw/foo, bar, baz/;

[download]

I normally like to stay away from global variables, but in this case I think you're right. The size of the script and the basic interaction make good reasons to have a couple of global variables... although I want to keep them read-only.

Thanks for all your help and the discussion :)
--
Ben
"Naked I came from my mother's womb, and naked I will depart."

Replies are listed 'Best First'.
(jeffa) 3Re: Code review and question for parts script
by jeffa (Bishop) on Oct 31, 2002 at 05:29 UTC
    I already /msg'ed this, but i should probably reply for the benefit of other readers. Check out A Guide to Installing Modules for info on how to install modules on servers you do not have root access for.

    As for use vars drop the commas in qw(): 

    use vars qw/foo bar baz/;

    [download]

    And finally, global variables ... yes they are generally considered bad design, but sometimes they can provide elegance that is, IMHO, worth more than the trouble not using them causes. The important thing is to not rely upon them heavily. I tend to favor OO for larger programs, but in a sense, an attribute is a global variable for an object. An object is just a convenient way to tuck away that variable/attribute when you don't need it. Consider a framework that 'HAS-A' database connection abstracted away in a object heirarchy somewhere: 
    # some base class that overrides a handler
sub handle {
   my ($self) = @_;
   my $dbh = $self->{dbh};
   my $ses = $self->{session};

   my $sth = $dbh->selectall_arrayref("
      select id from agents
   ");
   
   my $users     = [map { {user => $_->[0]} } @$sth];
   my $paramsout = {users => $users};

   return $paramsout;
}

    [download]
    (look familiar, maverick? ;))

    Here, making the database connection accessible as an attribute from an object not only makes more sense, it is necessary to keep 'things from getting out of hand'. But for small-ish utility scripts, this kind of abstraction is really overkill that gets it the way of 'getting stuff done'. Happy coding. :)

    jeffa

    L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom