Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Re: (jeffa) Re: Code review and question for parts script

by bprew (Monk)
on Oct 31, 2002 at 04:52 UTC ( [id://209344]=note: print w/replies, xml ) Need Help??


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/;

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/;

    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; }
    (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)
    

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://209344]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others wandering the Monastery: (2)
As of 2024-04-25 20:29 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found