Dose package name has to be the same as the filename? (for OO)

[Peng Yu]

Hi,

In this webpage, the package name is the same as the filename.

http://www.tutorialspoint.com/perl/perl_oo_perl.htm

I checked some perl modules, it seems that the filename is always the
same as the package name. I'm wondering if this is required. Or the
package name and the filename can be different?

Thanks,
Peng

 

[Sherm Pendley]

http://www.tutorialspoint.com/perl/perl_oo_perl.htm

I checked some perl modules, it seems that the filename is always the
same as the package name. I'm wondering if this is required. Or the
package name and the filename can be different?

In a non-OO module that exports functions, they have to be the same for
Exporter to do its thing. When you use() a module - let's call it "Foo",
the following steps are basically what happens:

BEGIN {
require Foo;
import Foo qw(args);
}

The second step is optional - if there's no import() function in module
Foo, the use() will still succeed.

Now, let's suppose that package Bar is in Foo.pm. Foo.pm is compiled by
the require() with no problems. Because its code is in package Bar, the
import() function, explicitly declared or inherited from Exporter, is
compiled into that package too.

But the use() still tries to call an import() function in package
Foo. Worse, because import() is optional it will *silently* fail. The
only clue the user will get that something has gone wrong, is that none
of the functions declared in package Bar will be usable without a fully-
specified package name, i.e. Bar::baz(), because the import() failed to
create aliases for them in the current package.

Other things can depend on the filename = package convention too. Take
perldoc, for example. If a user of your module runs "perldoc Foo" to get
your module's docs, it will read the docs found in Foo.pm. The user's
going to be confused if those docs describe a package named "Bar."

Even if your module is "pure" OO and doesn't export anything, following
the established convention helps avoid confusion - imagine a maintenance
programmer looking at your script a year from now, and seeing this:

use Foo;
my $bar = Bar->new();

It's not very intuitive to see a class Bar defined in Foo.pm.

So no, it's not required in theory. But the convention of naming them
the same is followed so widely, that in practice it's really more or
less required.

sherm--

 

[Peng Yu]

In a non-OO module that exports functions, they have to be the same for
Exporter to do its thing. When you use() a module - let's call it "Foo",
the following steps are basically what happens:

    BEGIN {
        require Foo;
        import Foo qw(args);
    }

The second step is optional - if there's no import() function in module
Foo, the use() will still succeed.

Now, let's suppose that package Bar is in Foo.pm. Foo.pm is compiled by
the require() with no problems. Because its code is in package Bar, the
import() function, explicitly declared or inherited from Exporter, is
compiled into that package too.

But the use() still tries to call an import() function in package
Foo. Worse, because import() is optional it will *silently* fail. The
only clue the user will get that something has gone wrong, is that none
of the functions declared in package Bar will be usable without a fully-
specified package name, i.e. Bar::baz(), because the import() failed to
create aliases for them in the current package.

Other things can depend on the filename = package convention too. Take
perldoc, for example. If a user of your module runs "perldoc Foo" to get
your module's docs, it will read the docs found in Foo.pm. The user's
going to be confused if those docs describe a package named "Bar."

Even if your module is "pure" OO and doesn't export anything, following
the established convention helps avoid confusion - imagine a maintenance
programmer looking at your script a year from now, and seeing this:

    use Foo;
    my $bar = Bar->new();

It's not very intuitive to see a class Bar defined in Foo.pm.

So no, it's not required in theory. But the convention of naming them
the same is followed so widely, that in practice it's really more or
less required.

Therefore, in one file, only one package can be defined practically,
right? If that is the case, why we still need to have the keyword
'package'? Why perl not just use the file name as the package name?

Thanks,
Peng

 

[Sherm Pendley]

Therefore, in one file, only one package can be defined practically,
right? If that is the case, why we still need to have the keyword
'package'? Why perl not just use the file name as the package name?

Because forcing the issue would not be the Perl Way (tm). Remember the
Perl motto - There Is More Than One Way To Do It, or TIMTOWTDI. What
this means in practice is, if you want to shoot yourself in the foot,
Perl will let you.

sherm--

 

[Uri Guttman]

PY> Therefore, in one file, only one package can be defined practically,
PY> right? If that is the case, why we still need to have the keyword
PY> 'package'? Why perl not just use the file name as the package name?

that is not the case. you can define multiple packages inside one file
and also define the SAME package name in multiple files. the package
name and file name are independent. the convention is to keep them the
same for most cases and to allow 'use' to properly call the correct
import method.

and there are very good reasons to allow that flexibility. some files
need extra subclasses and put the different packages into one
file. sometimes a large class is broken up into multiple files for ease
of editing and so have the same package name in different file.

uri

 

[Bart Lateur]

In this webpage, the package name is the same as the filename.

http://www.tutorialspoint.com/perl/perl_oo_perl.htm

I checked some perl modules, it seems that the filename is always the
same as the package name. I'm wondering if this is required. Or the
package name and the filename can be different?

It's not absolutely required, but import() won't work if they're
different. OO doesn't rely on import.

You can have multiple packages per file, and they may all be different
from the module file name.

So no, it's not required, but it's a habit likely to reduce the chance
of name clashes: if package name and file name are the same, and you kow
your file name is unique, then the package name will be unique too. Heh.

Besides, why wouldn't you pick the same name? You obviously must be
somewhat happy with it, or you wouldn't pick it for either. So giving
them both the same name doesn't seem so bad.

 

[Peter J. Holzer]

Therefore, in one file, only one package can be defined practically,
right? If that is the case, why we still need to have the keyword
'package'? Why perl not just use the file name as the package name?

No. You can have multiple packages in one file. For example, if you have
Foo.pm:

package Foo;
....
package Foo::Bar;
....
package Some::Other::Class::Related::To::Foo;
....
__END__

you can load it with "use Foo". Only the import method of "Foo" (if any)
will be called, but all three packages will be loaded and are available
in your program. So you can then call
Some::Other::Class::Related::To::Foo->new() if you want. But you cannot
"use Some::Other::Class::Related::To::Foo", because no file
Some/Other/Class/Related/To/Foo.pm exists - you have to "use Foo" to
load it. Sometimes it makes sense to put several packages into a single
file. But (apart from aesthetic reasons) only rarely - I think I needed
that maybe 2 or 3 times in over 10 years of Perl programming.

hp