Prev: Does this match any number or just single digit ones?
Next: FAQ 6.24 How do I match a regular expression that's in a variable?
From: HerbF on 6 Aug 2010 18:13 Uri Guttman wrote: >>>>>> "H" == HerbF <HerbF(a)earthlink.net> writes: > > >> sub calls should be made with parens is the common style rule and not > >> with &. > > H> Thanks. Do I understand you to say that &abc; is "wrong" and that I > H> should be using abc(); instead? > >yes. i just said that. so do the docs. please read them as that is the >best way to learn perl. there is a whole doc just for perl subs. > > H> As I'm calling one routine as &abc(A,B,C); what is the correct syntax? > >no, drop the & as it is NOT NEEDED nor desirable. it marks your coding >style as ancient perl4ish. it can cause issues you don't know about. >parens are all you need and are correct. > Thank you. HF
From: HerbF on 6 Aug 2010 18:14 Tad McClellan wrote: >HerbF(a)earthlink.net <HerbF(a)earthlink.net> wrote: >> Uri Guttman wrote: >> >>>>>>>> "H" == HerbF <HerbF(a)earthlink.net> writes: >>> >>> H> I typically call subroutines without using parenthesis, e.g., &abc;. I >>> H> have one routine where I pass variables and I call it as: >>> >>>that is poor perl code and perl4 style. don't use & for sub calls as it >>>has side effects you may not know about. read perldoc perlsub for more. >>> >>> H> Should I be using parenthesis at the subroutine, i.e., >>> >>> H> sub abc (A,B,C) {...} >>> >>>that has nothing to do with parens at the sub call itself. perl doesn't >>>support named arguments like you have there so it won't do any good to >>>try it. > > >What you have there is called a "prototype", they are often a Bad Idea, >so you shouldn't be using them at all. > >If what you want is named arguments, then you typically do that by >copying the args in the first statement in the subroutine body: > > sub abc { > my($A, $B, $C) = @_; > ... > >But don't choose one-letter variable names! Of course. :-) > > >>>sub calls should be made with parens is the common style rule and not >>>with &. >>> >> Thanks. Do I understand you to say that &abc; is "wrong" and that I should >> be using abc(); instead? > > >Yes. > > >> As I'm calling one routine as &abc(A,B,C); what is the correct syntax? > > >abc(A,B,C); > > > perldoc -q difference > > What's the difference between calling a function as &foo and foo()? Thanks very much. Herb
From: Peter J. Holzer on 7 Aug 2010 08:31 On 2010-08-06 21:28, Tad McClellan <tadmc(a)seesig.invalid> wrote: > HerbF(a)earthlink.net <HerbF(a)earthlink.net> wrote: >> Uri Guttman wrote: >>>>>>>> "H" == HerbF <HerbF(a)earthlink.net> writes: >>> H> Should I be using parenthesis at the subroutine, i.e., >>> >>> H> sub abc (A,B,C) {...} [...] > What you have there is called a "prototype", It isn't even a correct prototype. Perl complains with Illegal character in prototype for main::abc : A,B,C at foo line 3. if you use warnings at the definition and with Malformed prototype for main::abc: A,B,C at foo line 5. even without warnings and strict when you try to call that sub. So the OP could have gotten the answer "No" to his question simply by trying it. (I really don't understand people who post some code which doesn't work and ask "Should I do this?" Well, it doesn't work, so obviously you shouldn't.) hp
From: Keith Thompson on 9 Aug 2010 15:46 "Uri Guttman" <uri(a)StemSystems.com> writes: >>>>>> "H" == HerbF <HerbF(a)earthlink.net> writes: > H> I typically call subroutines without using parenthesis, e.g., &abc;. I > H> have one routine where I pass variables and I call it as: > > that is poor perl code and perl4 style. don't use & for sub calls as it > has side effects you may not know about. read perldoc perlsub for more. > > H> Should I be using parenthesis at the subroutine, i.e., > > H> sub abc (A,B,C) {...} > > that has nothing to do with parens at the sub call itself. perl doesn't > support named arguments like you have there so it won't do any good to > try it. > > sub calls should be made with parens is the common style rule and not > with &. I tend to omit parentheses in many cases where they're not necessary. For example, I might write: sub Foo; ... my $x = Foo 42; # rather than Foo(42) ... sub Foo { my($arg) = @_; return $arg + 1; } Would you consider this to be a bad habit? (I don't use "&" on calls, and I've broken my previous habit of using prototypes.) I know that parentheses are necessary for something like: print "Foo 42 = ", Foo(42), "\n"; because without them the "\n" is passed to Foo, not to print. -- Keith Thompson (The_Other_Keith) kst-u(a)mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"
From: Uri Guttman on 9 Aug 2010 16:00
>>>>> "KT" == Keith Thompson <kst-u(a)mib.org> writes: KT> I tend to omit parentheses in many cases where they're not necessary. KT> For example, I might write: KT> sub Foo; KT> ... KT> my $x = Foo 42; # rather than Foo(42) KT> ... KT> sub Foo { KT> my($arg) = @_; KT> return $arg + 1; KT> } that only works if you declare Foo before you call it. perl can't tell if a bareword is a sub if it hasn't seen it before unless you use parens. look at these examples which show why always using parens is a good thing: perl -we 'sub foo {print "hello\n" } ; foo' hello perl -we 'foo; sub foo {print "hello\n" }' Unquoted string "foo" may clash with future reserved word at -e line 1. Useless use of a constant in void context at -e line 1. perl -we 'foo(); sub foo {print "hello\n" }' hello KT> Would you consider this to be a bad habit? (I don't use "&" on KT> calls, and I've broken my previous habit of using prototypes.) yes, as i show above. btw, predeclaring also works for exported subs from a module. still i use parens. only with protoyped subs that need to look like builtins might i skip the parens. KT> I know that parentheses are necessary for something like: KT> print "Foo 42 = ", Foo(42), "\n"; KT> because without them the "\n" is passed to Foo, not to print. that is a precedence issue, not a predeclared one. if Foo were predeclared with a prototype of a single arg, the parens wouldn't be needed and it would work. uri -- Uri Guttman ------ uri(a)stemsystems.com -------- http://www.sysarch.com -- ----- Perl Code Review , Architecture, Development, Training, Support ------ --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com --------- |