Two, you wouldn't use Foo; inside Foo.pm. This Rosetta line is the statement which establishes the namespace for the subsequent implementation code. (Hence the comment following which shows what the header file implies.) In C++, both the user and the implementor of a class typically include the header file; in Perl, only the user would 'use' the file as if declaring the intent to call upon its interface.

--
[ e d @ h a l l e y . c c ]

Two, you wouldn't use Foo; inside Foo.pm.

True, but you that's because we don't separate the interface from the implementation in Perl. Even in C++, you could put the whole implementation in the header file if you chose to.

This Rosetta line is the statement which establishes the namespace for the subsequent implementation code.

But that's not at all what it does in C++ and, in fact, it wouldn't be uncommon to see various other #include's in the source file containing the implementation.

I stand by my original assertion. #include <Foo.h>; is much more analagous to use Foo; in Perl. In both cases, you are stating your intent to use the interface provided by the class/module/library/whatever called "Foo".

-sauoq
"My two cents aren't worth a dime.";

I haven't seen your method in use, but I've seen the hack.

This closure idiom is useful and used in all manner of situations.

{
    my $static_data;  # will persist between calls and IS PRIVATE

    sub do_stuff {

        my ( $arg1, $arg2, $reset ) = @_;

        # first set our static data if we have not been called before
        # if we have been called then $static_data will be defined
        # static_data can not be accessed outside of this block - ie s
+ub

        $static_data = _expensive_or_private_init() if $reset or ! def
+ined $static_data;

        # blah

    }
}
[download]

Besides the more obvious private variable usage it works well when you create complex data structures or expensive calls to a DB that you only want to do once

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print