{ promote my $language;
redo;
}What about declaring a variable in the block it's being used is so difficult for you? It's pretty simple... define a variable in the main namespace, it's a global. Define it in a block, it's lexical.
This is a bit of an oversimplification, but
Uh, that's not how perl works, that's how most languages work. With perl, if you define a variable in a block, its still package global. Variables are only lexical scope if they are declared with "my". Hence my complaining that you have to explicitly declare variables as local, when it should be assumed unless stated otherwise, like with most languages.
The bug/feature is that you can't declare variables unless you declare them either "local" (which is usually not what you want) or "my" (which _is_ what you usually want). The buggy aspects of this feature are mostly relieved by "use strict" and other pragma.
(Do NOT forget to "use strict" !)
I don't quite gather why you think declaring args to a sub is any more advantageous than passing args via @_. And yes, this can be a benefit when you might not need to pass all the args at any one time.
First of all, that's not a benefit. In most languages you can have optional arguments to functions, without forcing all functions to take only a single array of scalar variables.
extern int setPixel( long red, long green, long blue, long x, long y );
A parameter list is an array. Syntactic sugar that allows type enforcing by position in the parameter array in a prefix grammar of parenthesized lists is useful, but, as is pointed out, prototypes can provide the more useful forms of type enforcement in relatively modern perl.
Perl also provides for passing parameters as a hash instead of an array. The good part of that is that if you pass red, green, and blue, you don't have to remember whether red, green, or blue came first in the list. The bad part of this is left as an exercise for the reader. (I'd give an example, but my head is so full of Java these days I couldn't guarantee getting the syntax right.)
Declaring args makes it quick and easy to see what arguments a function takes, even if you are a script and not a person.
Well, at least it does if you can remember the significance of order when passing a bunch of 32 bit integers.
It also lets you require certain args, set defaults for args, and pass non scalar args, without wasting extra time doing that work yourself.
Which can also be done in perl, and TMTOWTDI, of course.
With perl you can only pass an array as a reference, if you want a second array you have to copy the one passed as a reference manually in the sub.
Not exactly true, although getting the hang of passing arrays can take some time. (And reading code that does it the right way can be something of an adventure, especially for programmers who are mostly experienced in descendants of Algol.)
And of
course, if all you want is an array of args, languages that let you
declare arguments to functions can give you that just fine. Perl is
all about being flexible and saving programmer time, yet something basic
like functions is implimented in an inflexible way that requires
programmers to spend extra time checking args. Declaring args is both
more flexible, and a time saver.
Not true. The problem is not inflexibility, but once again too much flexibity. Of the several ways to solve the problems of passing parameters in perl, the one that is closest to traditional procedure parameter lists is perhaps a bit too spare in its requirements.
--
Joel Rees
Getting involved in the neighbor's family squabbles is dangerous.
But if the abusive partner has a habit of shooting through his/her roof,
the guy who lives upstairs is in a bit of a catch-22.
