Questions about multiple packages in one file 1

[whn]

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]

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.

 

[dkyrtata]

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]

Thanks for the reply, max & dkyrtata.

Here is a simplied example:

package Flag::Data;
use strict;[COLOR=red]
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.", },
    },
});[/color]

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:ata'?
2) What would happen if I put the block code in red in the package 'Flag' and remove the package 'Flag:ata'?

Thanks.

 

[dkyrtata]

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:ata", those references must always be qualified. So if you had a variable, $indicator_data, in your "Flag:ata" package, it would have to be referenced with a qualifier within the "Flag" package:

$Flag:ata::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:ata" 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:ata" 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:ata" (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]

Thank you so much for your dkyrtata! I am clearer now. But I will revisit your post later for sure.

Thanks again.