Re: beginner, intermediate, and advanced scripting

[Joel Rees <joel_rees_(_at_)_sannet_(_dot_)_ne_(_dot_)_jp>]

{	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.