Re^4: Many strings make one variable?

One could spend hours telling you how dangerous using perl is when you use the shebang line.

Yes, all the Perl vets will spend hours telling you why not to use softrefs. Of course, you're more clever than them.

And CGI is for whimps too, isn't it? You're more clever than Lincoln Stein, and Ovid who spent hours explaining why handrolled CGI parameter parsers are dangerous doesn't have a clue either.

Nor have you understood what local does, either. You want my $in = $_[0]; there, and if you knew what it does, you would have known that local $$lname = $lvalue; has to fail (and why) at first glance.

I downvoted your note and was shocked to see people had upvoted you.

Makeshifts last the longest.

Comment on Re^4: Many strings make one variable?

Replies are listed 'Best First'.
Re: Re^4: Many strings make one variable? by true (Pilgrim) on Oct 15, 2002 at 09:33 UTC
The line `my $in = $_[0];` [download] has nothing to do with the original test i did. the local test came in with the line "local $lname" vs $lname. Just had a nice read on 'my' pretty cool but 'local' works to. see original question: 205160 I also just read local is better than 'my' for file handles perlman:perlsub NOTE: In general, you should be using ``my'' instead of ``local'', bec +ause it's faster and safer. Exceptions to this include the global pun +ctuation variables, filehandles and formats, and direct manipulation +of the Perl symbol table itself. Format variables often use ``local'' + though, as do other variables whose current value must be visible to + called subroutines. [download]	[reply] [d/l] [select]
Re^6: Many strings make one variable? by Aristotle (Chancellor) on Oct 15, 2002 at 09:51 UTC
No, it doesn't have anything to do with it, nor does the fact that you're parsing CGI parameters on your own. But what peeved me is how you dismissed Dominus' arguments off hand and then you followed up with a bunch of typical ignorant mistakes, when it was obvious you didn't even understand what local does. `local` seems to work where my should be used because it does what seems to have the same effect, even though it's completely different from what you want. Sorry for flying off the handle that badly, but you appeared quite unwilling to learn, and it seems you're not after all. Maybe you just "learned" Perl from reading other people's scripts? That frequently teaches awful habits because a lot of the freely available Perl code out there is really awful. If you want to continue that approach, I suggest you check out the NMS archive. Those scripts where expressly written to be an example of good code. merlyn's many various columns also contain well written (if sometimes a bit condensed) code. I really suggest you get a good book, though. The O'Reilly Llama book is a manageable size and a decent intro, although you'll probably want to skip the chapter or two at this point. The rest of their Perl books are also good; the Camel book is the "standard" reference on Perl, but has grown to a pretty hefty size in its 3rd edition. The Book Reviews section here on this site may also be helpful. Makeshifts last the longest.	[reply]
Re: Re^6: Many strings make one variable? by true (Pilgrim) on Oct 15, 2002 at 10:44 UTC
The following page has been very helpful to me with regards to 'my' versus 'local'. Thanks for the link Aristotle. http://perl.plover.com/local.html jtrue	[reply]
Re: Re: Re^4: Many strings make one variable? by demerphq (Chancellor) on Oct 15, 2002 at 10:46 UTC
I also just read local is better than 'my' for file handles Yes this is true for advanced scenarios. However using anonymous filehandles available in 5.6 and later (or is it earlier as well?) avoids almost all of the scenarios where localising a filehandle is necessary. (Well, an exception being when dealing with older code that still uses dynamic filehandles instead of anonymous ones) `open my $private_filehandle,"<",$0 or die "Weird! failed to open mysel +f ($0) : $!";` [download] Local is only really needed when localizing special filehandles like STDOUT and the like, or when localizing special variables like @ARGV and $_ and %ENV or whatever. (Actually this is not strictly true, sometimes using dynamic scoping is a powerful way to configure a module, for instance Data::Dumper, but of course that was written by a real guru, and the justifications are beyond the scope of your skills and this reply.) The note you post is most likely from an earlier version of perl, or hasnt been updated since an earlier version of perl. --- demerphq my friends call me, usually because I'm late....	[reply] [d/l]