If you've looked at the Camel book and don't understand the "$parm" lines, then perhaps you're in a bit deeper than you think, and might do well to consider a range of options broader than buying a newer edition of the Camel book.
If whoever did the tasking knows you haven't coded for 3 years, and nonetheless assigned the work to you, how important is it for them? If the answer if "very", then you could either lobby to have the work assigned to someone whose skills or more current, or you could lobby to bring in a contracter to work on the code and help you get up to speed. If none of these options are viable, you may be stuck in a bad situation, and might take that as a clue to dust your resume off.
Assuming that the situation isn't the dire, I suggest looking for ways to boost your trip up the learning curve. Finding someone local to you who knows Perl, and convincing/bribing/paying them for some handholding might get you there faster than just reading a book. Some people (I am one) learn faster when they can look over someone's shoulder for a while.
On the book front, Learning Perl might be a more approachable alternative to the Camel book, though the latter is nearly a required reference.
| [reply] |
So you've been tasked with managing code you didn't write, in a language your not used to, and you've forgotten what it's like to be in code mode? Is that what's troubling you Bunkie??
As the tortured prisoner in Monty Python's "Life of Brian" says,
You lucky bastard!
I think just by digging into Perl you'll soon find yourself delighted that it was Perl you inherited. It's allot easier than the alternatives and if you have to pick code back up there's none more fun to learn. Depending on the quality of the code you've inherited you may be better off re-writing chunks of it rather than 'managing' it.
You might want to actually go to the bookstore to compare "Leaning Perl" and "Elements of Programming Perl" both are great books that you've got to decide your own personal style preference when deciding upon (I keep both around).
Welcome back to the code,
coreolyn
| [reply] |
It's not a Perl keyword, just someone's choice of variable name
short for "parameter". I use it all the time myself...
Update: No, I didn't mean "param" as in CGI, though I
often utilize it there for instance.
Mike - mps@discomsys.com
"The two most common elements in the universe are hydrogen... and stupidity."
Harlan Ellison
| [reply] |
Well, lets assume the original programmer was considerate and used meaningful variable names. If the things with the "$parm" are of this style:
if ( $parm{something} eq 'a value' ) {
#do something
}
Then the $parm is really a hash (see page 50 onwards in your Camel). You may find that a number of different values being passed to the program are grouped in the %parm hash (note the name now starting with a percent sign). So somewhere at the start of the program could be a routine to read the command line parameters, and set the key / value pairs of a hash.
Another good Perl book is the "Perl Cookbook" (also called the Ram book because of the funky big horn sheep on the cover). Jam packed full of real life examples - this shows you how you actually use all those cool things written about in the Camel.
| [reply]
[d/l] |
"$parm" means one thing to me: CGI
If you don't see this line in the code, preferrably
at the top:
use CGI;
then you should look into using CGI.pm. There must be
50 reasons to use CGI.
Jeff
R-R-R--R-R-R--R-R-R--R-R-R--R-R-R--
L-L--L-L--L-L--L-L--L-L--L-L--L-L--
| [reply]
[d/l] |
Hi hackadelic, I know that you are knew to the monastary, but from past experiences of mine... you may want to title your questions a bit more detailed that just 'st00pid, remedial' etc... thanks! ... just tryin' to help.
bladx ~ ¡muchas veces tengo preguntas! | [reply] |