Hi sachinz2,

Packages can be declared (nearly) anywhere. A package declaration changes the current package name/namespace, and the new namespace is independent of the previous one, even if it's declared "within" another package - except that the two lexical scopes can overlap. In the case of OO, names do not matter - a class/package named "Foo::Bar" is not automatically related to "Foo" in any way, nor is a class/package declared within another class/package automatically related to its outer class, again except in the lexical scope (note that normal sub definitions/calls don't cross the package boundary via the lexical scope, as shown in the example below). The only way to establish an OO relationship is via @ISA and its helpers like base and parent. I'd suggest you have a look at package as well as "Packages" and "Symbol Tables" in perlmod, and then have a look at this example:

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

our $pack = __PACKAGE__; # $main::pack
print "$pack\n";         # prints "main"

package Foo;
our $pack = __PACKAGE__; # $Foo::pack
print "$pack\n";         # prints "Foo"

package Bar;
our $pack = __PACKAGE__; # $Bar::pack
print "$pack\n";         # prints "Bar"
yak();                   # defined below, prints "yak: Bar"

package Foo::Bar;
our $pack = __PACKAGE__; # $Foo::Bar::pack
print "$pack\n";         # prints "Foo::Bar"
sub yak {                # Foo::Bar::yak()
    print "yak: ".__PACKAGE__."\n" }
yak();                   # prints "yak: Foo::Bar"

{ package Foo;
    # now back to package "Foo", nested in a new block
    our $blah = __PACKAGE__; # $Foo::blah
    print "$blah\n";         # prints "Foo"
    print "$Foo::pack\n";    # $Foo::pack is still "Foo"
    print "$Bar::pack\n";    # and $Bar::pack is still "Bar"
    # however, "$pack" access the most recent lexical definition
    print "$pack\n"; # so this is actually $Foo::Bar::pack, "Foo::Bar"
    # yak(); # but this doesn't work, there is no Foo::yak!
    
    { package Bar; # and back in package "Bar"
        # but we're still in the most recent lexical scope
        print "$pack\n"; # so this is still $Foo::Bar::pack, "Foo::Bar
+"
        print "$blah\n"; # and this is still $Foo::blah, "Foo"
        sub yak {        # Bar::yak()
            print "yak: ".__PACKAGE__."\n" }
        yak();           # prints "yak: Bar"
    }
}
[download]

If you have further questions, I'd suggest you ask them with code to illustrate your question (see for example Short, Self Contained, Correct Example and How do I post a question effectively?).

Hope this helps,
-- Hauke D

Updated: Minor updates to wording for clarification.

Hello sachinz2,

From perlmod#Packages:

Packages may themselves contain package separators, as in $OUTER::INNER::var. This implies nothing about the order of name lookups, however. There are no relative packages: all symbols are either local to the current package, or must be fully qualified from the outer package name down. For instance, there is nowhere within package OUTER that $INNER::var refers to $OUTER::INNER::var. INNER refers to a totally separate global package.

So, although package declarations can be nested using braces, they’re still independent of each other. That is, a pair of declarations like this:

package A
{
    ...

    package B
    {
        ...
    }   
}
[download]

is really no different to this:

package A;
...

package B;
...
[download]

(Note that the A::B syntax is used to specify where Perl looks for the package: in this case, it will look for package B in a subdirectory A of one of the directories specified in @INC. But from an OO point of view, packages A and B are unrelated.)

Hope that helps,

In the Code , I found , a (actually more then one) Package, being declared in another Package.

I assume by that you mean you have a file with more that one package statement in it; and those package statements have different names after them?

Functions and methods become a part of whatever package is currently in force. So in this snippet:

package A;

sub fred { ... }

package B;

sub bill { ... }

package C; 

sub mary { ... }

package B;

sub joan{ ... }

package A;

sub cleo{ ... }
[download]

There are five functions declared in three packages: A::fred() & A::cleo(); B::bill()/c> & <c>B::joan(); C::mary()

The number and ordering of package statement within a file is completely flexible; a subroutine belongs to whatever package (statement) is in force at the time of its definition.

It is also quite possible to split packages across multiple files; though the are generally less good reasons for doing so.

Hi

No Not like that, What I have is like this,

Package A::B::C;

1;

Package A::B::D;

sub abc {..... ... }

sub xyz { ......... }

Package A::B::E

sub new{ ..... }

Package A::B::F

use base (A::B::E);

Packge A::B::G

use base (A::B::E);

The same basics apply.

The number of elements in the name doesn't matter, it is still just a name.

Any 'relationship' between packages with the same prefix is implied -- for human consumption only -- they are entirely independent as far as Perl is concerned.

Those packages with the statement use Base (X::Y::Z) at the top, are subclasses of the named package, which does define an OO relationship between them, such that the subclassing package (those with use Base ...), inherit (or overide) all the code (functions/methods) from the named base package.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)

In the absence of evidence, opinion is indistinguishable from prejudice.

This looks like it might just be done for organization or structural purposes, or perhaps to save memory if A::B would be a huge module to load. It should be possible to just have a "Package A::B" at the top without having to specify ::C-F, I might be wrong though.

Check out this page, specifically the "Naming of modules" section.

Thankyou

And Yes I am going through all the links mentioned by you