Re: Good package practices

Use @EXPORT instead of @EXPORT_OK in your module file.

With that said, however, for my own stuff I prefer the OO method. Here's a very simplified example.

package My::Example;

sub new { return bless {}; }

sub GetLinks { # ... }
[download]

And then...

#!/usr/bin/perl
use warnings;
use strict;

use lib '/path/to/lib';
use My::Example;

my $example = My::Example->new();
my $links = $example->GetLinks();
[download]

Comment on Re: Good package practices Select or Download Code

Replies are listed 'Best First'.
Re^2: Good package practices by joe_kool (Novice) on Jan 26, 2006 at 22:31 UTC
Thank you for the suggestion. I have a couple of objects in this application too, but I was wondering what was the good way to go for plain librairies... I'm not exactly sure what changing EXPORT_OK to EXPORT was supposed to do in this situation, though... I can still access any function from webData.pm in login.cgi if I put the full package name before the function name, even if it is not in the webData's EXPORT list or even if it is not in the keyword list when I do `use webData qw();`... I would like to prevent, for example, GetEmails from being accessed in login.cgi if it is not in the EXPORT list, or if it is not in the keyword list of the `use webData qw();` Moreover, I still can't call in login.cgi main code the function `GetLinks` without specifying the full package name (as in `my $links_ref = MyPackages::Config::webData::GetLinks();`).	[reply] [d/l] [select]
Re^3: Good package practices by kwaping (Priest) on Jan 26, 2006 at 22:46 UTC
`@EXPORT` should let you use GetLinks() without the namespace prepended to it. Read the Exporter docs for more info. In regards to keeping a module's method private, read this little snippet from perltoot: Perl doesn't impose restrictions on who gets to use which methods. The public-versus-private distinction is by convention, not syntax.	[reply] [d/l]
Re^2: Good package practices by joe_kool (Novice) on Jan 27, 2006 at 20:14 UTC
	[reply]