Smart questions
Smart answers
Smart people
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Member Login




Remember Me
Forgot Password?
Join Us!

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips now!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

Join Tek-Tips
*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.
Jobs from Indeed

Link To This Forum!

Partner Button
Add Stickiness To Your Site By Linking To This Professionally Managed Technical Forum.
Just copy and paste the
code below into your site.

Questions about multiple packages in one fileHelpful Member! 

whn (Programmer) (OP)
27 Oct 10 13:05
Experts,

What are the advantages to put multiple packages in one file? What are the common loopholes in this kind of implementation, if any? Could someone tell me where I can find some documentations that discuss this topic?

Explainations with examples are highly appreciated.
max1x (Programmer)
29 Oct 10 16:47
What do mean by packages; A Software bundle that has modules directory?  Or a main program that inherits multiple packages?

It all depends on what you are creating and how you are deploying it.
 
Helpful Member!  dkyrtata (Programmer)
31 Oct 10 1:08
I have used multiple package declarations (i.e name spaces) in one file to group related subroutines within each name-space.

In one library I wrote, I had a single function in the main package, and all the supporting routines in different packages - but all in the same file. The idea is that I did not want the supporting routines to be in the main name-space which can inadvertently be called by someone's program intending to call their own routine of the same name by coincidence. (the library was not using Object-oriented programming)

I never had a problems with that setup.

What kind of problems have you anticipated?  
whn (Programmer) (OP)
5 Nov 10 9:13
Thanks for the reply, max & dkyrtata.

Here is a simplied example:

CODE

package Flag::Data;
use strict;
use AutoVars;
use base 'AutoVars::Hash';
AutoVars::Template::defineTemplate({
    description => "DUT Flag Attributes",
    vars =>{
    freeBy => { default=>0, description=>"The time that the flag should be released by.", },
    },
});


package Flag;

require 5.006_001;
use strict;
use warnings;
sub new {
    # some implementations here
    return ($self);
}
# More subroutines here
1;

The file name is Flag.pm. My questions are:
1) What is the advantage to have a separated package 'Flag::Data'?
2) What would happen if I put the block code in red in the package 'Flag' and remove the package 'Flag::Data'?

Thanks.
 
dkyrtata (Programmer)
5 Nov 10 11:55
As far as I know, having multiple packages (or name-spaces as they can be called) allows you to group related objects together and segregate objects that are less related into other packages.

If your "Flag" package makes constant references to the objects in "Flag::Data", those references must always be qualified. So if you had a variable, $indicator_data, in your "Flag::Data" package, it would have to be referenced with a qualifier within the "Flag" package:

$Flag::Data::indicator_data
or
$Flag'Data'indicator_data

That can make your code look more cluttered than if the variable was in the "Flag" package where it would not have to be qualified. So you may be tempted to keep everything in the same package.

However, if you don't want users who are using objects in "Flag" to reference the $indicator_data variable, you would be inclined to hide it within the "Flag::Data" package.

In essence, you would be structuring your file to tell your users of your package that they are free to use everything in the "Flag" name-space, but not in the  "Flag::Data" name-space where you might want to change the behavior or structure of the objects in future.

Of course, you can segregate even further and put each package in its own file. That might be particularly helpful when packages are hundreds/thousands of lines long. As a personal preference however, I prefer to have everything I need in one file rather than jumping around from file to file trying to find where referenced objects are declared in. I hope that answers your first question.

By the way, I have never seen a package declaration like "Flag::Data" (with "::"), but my test shows that it works no differently than if it was declared as "FlagData". Perhaps there is a difference but I did not encounter it.


 
whn (Programmer) (OP)
5 Nov 10 16:37
Thank you so much for your dkyrtata! I am clearer now. But I will revisit your post later for sure.

Thanks again.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members!

Back To Forum

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close