declaring variables
In one of my scripts I have lots of variables to declare. I wanted to type them in groups instead of one long line but I think dividing my lines trough the use of the ENTER key stops the script from working. (Although when I check the syntax through "perl - c script.cgi" it gives me OK). Basically instead of this: my( $varaible1, $variable2, $variableA, $varaibleB); I wanted to type this: my( $varaible1, $variable2, $variableA, $varaibleB ); Any reason why it shouldn't work? Thanks, Mariusz
Re: declaring variables
Mariusz wrote: > > In one of my scripts I have lots of variables to declare. I wanted to type them in >groups instead of one long line but I think dividing my lines trough the use of the >ENTER key stops the script from working. (Although when I check the syntax through >"perl - c script.cgi" it gives me OK). > > Basically instead of this: > my( $varaible1, $variable2, $variableA, $varaibleB); > > I wanted to type this: > my( $varaible1, $variable2, > $variableA, $varaibleB > ); > > Any reason why it shouldn't work? No. John -- use Perl; program fulfillment -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: declaring variables
Stuff the variable names into an array, use a regex to delete all the slashes (as you will declare the names with a slash in front of it). Or anything like that. Actually, I think the syntax is ok. I'm sure local() can do this, so why can't my? Just try to accomplish something else with this construct, I'm sure it'll work. -- Bob Erinkveld (Webmaster Insane Hosts) www.insane-hosts.net MSN: [EMAIL PROTECTED] From: "Mariusz" <[EMAIL PROTECTED]> To: "perl" <[EMAIL PROTECTED]> Subject: declaring variables Date: Thu, 12 Dec 2002 20:47:15 -0600 In one of my scripts I have lots of variables to declare. I wanted to type them in groups instead of one long line but I think dividing my lines trough the use of the ENTER key stops the script from working. (Although when I check the syntax through "perl - c script.cgi" it gives me OK). Basically instead of this: my( $varaible1, $variable2, $variableA, $varaibleB); I wanted to type this: my( $varaible1, $variable2, $variableA, $varaibleB ); Any reason why it shouldn't work? Thanks, Mariusz _ Ontvang je Hotmail & Messenger berichten op je mobiele telefoon met Hotmail SMS http://www.msn.nl/jumppage/ -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Different ways of declaring variables
I am wondering about the different ways of initializing a single scalar. usual method: my $variable; but I am trying to get what (if anything) is being done differently by this : my ($variable); Thanks! Scott Lutz Pacific Online Support Phone: 604.638.6010 Fax: 604.638.6020 Toll Free: 1.877.503.9870 http://www.paconline.net -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Different ways of declaring variables
On Mon, 2002-05-13 at 18:07, Scott Lutz wrote: > I am wondering about the different ways of initializing a single scalar. > > usual method: > my $variable; > > but I am trying to get what (if anything) is being done differently by > this : > my ($variable); > > Thanks! > > > Scott Lutz > Pacific Online Support > Phone: 604.638.6010 > Fax: 604.638.6020 > Toll Free: 1.877.503.9870 > http://www.paconline.net The parentheses allow you to declare more than one variable at a time like this: my ($id, $name, $age); They also allow you to do a list assignment (instead of a scalar assignment) like this: my ($id, $name, $age) = $sth->fetchrow_array; -- Today is Pungenday the 60th day of Discord in the YOLD 3168 Missile Address: 33:48:3.521N 84:23:34.786W -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Different ways of declaring variables
To add what Chas mentioned, it also changes the context of the expression. One good example is the localtime() function. In "scalar" context it returns a date string, and in "list" context it returns a list of the date parts. When you use the parens on the left side of the assignment you are forcing list context. Try these two bits of code and see the difference in the output: my $x = localtime; print $x; my ($x) = localtime; print $x; Rob -Original Message- From: Chas Owens [mailto:[EMAIL PROTECTED]] Sent: Monday, May 13, 2002 6:11 PM To: Scott Lutz Cc: Beginners (E-mail) Subject: Re: Different ways of declaring variables On Mon, 2002-05-13 at 18:07, Scott Lutz wrote: > I am wondering about the different ways of initializing a single scalar. > > usual method: > my $variable; > > but I am trying to get what (if anything) is being done differently by > this : > my ($variable); > > Thanks! > > > Scott Lutz > Pacific Online Support > Phone: 604.638.6010 > Fax: 604.638.6020 > Toll Free: 1.877.503.9870 > http://www.paconline.net The parentheses allow you to declare more than one variable at a time like this: my ($id, $name, $age); They also allow you to do a list assignment (instead of a scalar assignment) like this: my ($id, $name, $age) = $sth->fetchrow_array; -- Today is Pungenday the 60th day of Discord in the YOLD 3168 Missile Address: 33:48:3.521N 84:23:34.786W -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Disadvantages of "our" v. "my" when declaring variables
Hello, I've started experimenting with the use of subroutines in place of large, repeating blocks of code in a few of my programs. Without exception, these subroutines require variables defined outside of the subroutine. Unless I'm mistaken, the only way to make these variables available within the subroutine is to define them as global variables using "our." As I replace code (and, I'm sure, as I move forward with new tasks), this is going to involve a lot of finding the original variable declaration to change "my" to "our." Is there some way around this? What are the disadvantages to using "our" in a fairly widespread manner, to avoid having to waste time going back and making the substitutions. Thanks for any input. Regards, Owen
Re: Disadvantages of "our" v. "my" when declaring variables
> "OC" == Owen Chavez writes: OC> I've started experimenting with the use of subroutines in place of OC> large, repeating blocks of code in a few of my programs. Without OC> exception, these subroutines require variables defined outside of OC> the subroutine. Unless I'm mistaken, the only way to make these OC> variables available within the subroutine is to define them as OC> global variables using "our." experimenting? as in maybe they would help your code? drop the experiment and just use subs. there is no way it won't improve your code massively. even for non-repeating code, subs organize your code so you can see what is happening. long linear programs are the worst form of coding style other than spaghetti code. as for your scoping issues, the way to use subs best is to pass arguments to them. needing globals means your program is poorly designed. you can group related variables into a hash and pass a reference to that. there are many ways but globals are rarely actually needed. OC> As I replace code (and, I'm sure, as I move forward with new OC> tasks), this is going to involve a lot of finding the original OC> variable declaration to change "my" to "our." Is there some way OC> around this? What are the disadvantages to using "our" in a OC> fairly widespread manner, to avoid having to waste time going back OC> and making the substitutions. our declares a lexical short name for a GLOBAL variable in the symbol table. it means that variable can be access and modified from anywhere in the program. nasty. my variables are scoped to the smallest enclosing block or file (or eval string but ignore that). this keeps them safe from other code which could do harm. uri -- Uri Guttman -- u...@stemsystems.com http://www.sysarch.com -- - Perl Code Review , Architecture, Development, Training, Support -- - Gourmet Hot Cocoa Mix http://bestfriendscocoa.com - -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Disadvantages of "our" v. "my" when declaring variables
On Fri, Oct 15, 2010 at 11:40 PM, Owen Chavez
wrote:
> I've started experimenting with the use of subroutines in place of large,
> repeating blocks of code in a few of my programs. Without exception, these
> subroutines require variables defined outside of the subroutine. Unless I'm
> mistaken, the only way to make these variables available within the
> subroutine is to define them as global variables using "our."
You, good sir, are mistaken. :) Globals are very rarely /required/.
Subroutines accept arguments for a reason. Not only does it make them
reusable for different sources of data, but it also restricts their
influence over the program. Global variables are accessible by the
entire program. Even file scope[1] variables are accessible by an
entire file! That means that you have a lot more chances to make a
mistake that causes a bug that makes the code do the wrong thing. `my`
is your friend in this regard.
Basically no matter which programming language you are using you
typically want to avoid global scope whenever you can. Take an hour
out of your life to watch the following video (even if you don't
understand it right away):
http://www.youtube.com/watch?v=-FRm3VPhseI
It's somewhat Java-centric, but it applies to basically all
programming languages. The more code that is allowed to access a given
piece of data the more likely that the program is to incorrectly
manipulate that data. The code is written by people and people are
fallible.
In Perl, arguments can be passed to your own custom subroutines the
same way that they are passed to built-in subroutines. As
comma-separated lists, "optionally" enclosed in parenthesis. For
example:
#!/usr/bin/env perl
use strict;
use warnings;
# Passes "foo", "bar", "baz", and "\n" to print.
print "foo", "bar", "baz", "\n";
# Same as above.
print("foo", "bar", "baz", "\n");
sub print_sum
{
my ($a, $b) = @_;
print($a + $b, "\n");
}
# Passes 5 and 10 to print_sum.
print_sum 5, 10;
# Same as above.
print_sum(5, 10);
my $lhs = 5;
my $rhs = 10;
# Passes the values of $lhs and $rhs to print_sum.
# Effectively, the same as above.
print_sum($lhs, $rhs);
__END__
Argument passing allows you to limit /scope/, which is very important
for reliable coding. It can be acceptable to use global variables for
simple scripts, but if you're writing non-trivial programs then you
should probably avoid global /state/ and try to limit scope as much as
possible.
[1] http://en.wikipedia.org/wiki/Scope_(programming)
--
Brandon McCaig
V zrna gur orfg jvgu jung V fnl. Vg qbrfa'g nyjnlf fbhaq gung jnl.
Castopulence Software
Re: Disadvantages of "our" v. "my" when declaring variables
Hi Brandon,
Just a note about your code:
On Saturday 16 October 2010 06:53:29 Brandon McCaig wrote:
> sub print_sum
> {
> my ($a, $b) = @_;
>
> print($a + $b, "\n");
> }
You should not call lexical variables "$a" and "$b" because this interferes
with the "$a" and "$b" http://perldoc.perl.org/perlvar.html variables used in
perldoc -f sort and now other functions. Reading from there:
{{{
* $a
* $b
Special package variables when using sort(), see sort. Because of this
specialness $a and $b don't need to be declared (using use vars, or our())
even when using the strict 'vars' pragma. Don't lexicalize them with my $a or
my $b if you want to be able to use them in the sort() comparison block or
function.
}}}
Regards,
Shlomi Fish
--
-
Shlomi Fish http://www.shlomifish.org/
List of Portability Libraries - http://shlom.in/port-libs
She's a hot chick. But she smokes.
She can smoke as long as she's smokin'.
Please reply to list if it's a mailing list post - http://shlom.in/reply .
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
