thanks ... that helps. I wish I could get the OO concept; I've gone through the perl manpages; I've got every ORA perl book; I've got the Conway book. The only thing I don't have is understanding. ;-)

I'll just keep working towards that goal of being just another perl hacker! thanks again. -s-

I wish I could get the OO concept; I've gone through the perl manpages; I've got every ORA perl book; I've got the Conway book. The only thing I don't have is understanding. ;-)

I know I'm in a minority here, but I usually have problems with Perl documentation (in whatever form) first time out. It is seldom self-contained (frequently referring to something else in Perl you don't know anything about).

My advice on Perl OO (or Perl anything) is:

• read the documentation
• do the examples
• do something original with a knowledgable person in the vicinity for questions
• after a while, re-read the documentation; you'll get a deeper understanding of the topic, and because you've learned other Perl things since the first reading, you'll understand why you didn't get it the first time :)

Heh. I was the one that suggested you use a tied hash.

You need to be careful about one point: "exporting" is not the same as "exposing an interface". In Perl has, "export" has a precise meaning (to introduce symbol table entries into the caller's main package), whereas an interface style is strictly a design decision. The two are related, but not the same thing.

Let me elaborate. Say you choose to present a function-oriented interface. You can choose to export the functions (using the standard Exporter module as your example code is doing). That means when I use the module, I get those sub symbols entered in my main package, potentially clashing with my own variable names or those from other packages.

I can keep the function oriented interface but not export any names by using an object-oriented interface. So, for example, instead of this:

use AIX::Sysinfo;
...
my $host = hostname();           # sub exported from module
my $version = system_version();  # sub exported from module
[download]

Use AIX::Sysinfo;
...
my $sys = AIX::Sysinfo->new();
my $host = $sys->hostname();
[download]

The same consideration applies to an interface exposed through variables, in this case a hash. I can choose to export the hash from my code, polluting my caller's namespace, or I can allow the caller to choose names by tying. Here's the first way:

use AIX::Sysinfo_var;                       # making this up
my $hostname = $sysinfo_hash{hostname};     # making this up
my $version  = $sysinfo_hash{aix_version};
[download]

use AIX::Sysinfo_tie;
...
tie %sysinfo, 'AIX::Sysinfo';
my $hostname = $sysinfo{hostname};
[download]

HTH

more excellent guidance... I wish I had the skills to implement your suggestion (esp. regarding the "tie"); hopefully, I will soon!

thanks, -s-

I agree that exporting functions is generally to be prefered to exporting variables, but obviously this is heavily dependent on the circumstances.

In your module, will the majority of users need all (or even most) of the functions each time they use it? And what determines the return values. It sounds like they are fixed for each program run, but need to be calculated once - is that right?

If that's the case, then it really sounds like you'd be best advised to use an object (and Conway's book is the clearest intorduction that I know of to Perl OOP) but in the short term why not consider just exporting one function that returns the hash of values.

use SomeModule;

my %hash_of_stuff = get_hash_of_stuff;
[download]

Perl Training in the UK <http://www.iterative-software.com>

thanks ... I think that this is a really good suggestion. Until I can properly grok the OO concepts and syntax, I'll export a single function that returns a hash of all the other items. If the user wants all of the functions available, they can access them directly.

thanks again! -s-

Remember that if they have to, your users can always use the fully-qualified name of your variable. But it's better to provide access to package data via a method, and even better to not export anything and use the OO interface.

I often use modules and explicitly import nothing at all:

use File::Find ();
[download]