Prev: Can not intercept and disable MouseWheel on a canvas
Next: How to ignore newline in Parse::RecDescent
From: PerlFAQ Server on 21 Apr 2010 18:00
This is an excerpt from the latest version perlfaq7.pod, which
comes with the standard Perl distribution. These postings aim to
reduce the number of repeated questions as well as allow the community
to review and update the answers. The latest version of the complete
perlfaq is at http://faq.perl.org .

--------------------------------------------------------------------

7.26: How can I find out my current or calling package?

(contributed by brian d foy)

To find the package you are currently in, use the special literal
"__PACKAGE__", as documented in perldata. You can only use the special
literals as separate tokens, so you can't interpolate them into strings
like you can with variables:

my $current_package = __PACKAGE__;
print "I am in package $current_package\n";

This is different from finding out the package an object is blessed
into, which might not be the current package. For that, use "blessed"
from "Scalar::Util", part of the Standard Library since Perl 5.8:

use Scalar::Util qw(blessed);
my $object_package = blessed( $object );

Most of the time, you shouldn't care what package an object is blessed
into, however, as long as it claims to inherit from that class:

my $is_right_class = eval { $object->isa( $package ) }; # true or false

If you want to find the package calling your code, perhaps to give
better diagnostics as "Carp" does, use the "caller" built-in:

sub foo {
my @args = ...;
my( $package, $filename, $line ) = caller;

print "I was called from package $package\n";
);

By default, your program starts in package "main", so you should always
be in some package unless someone uses the "package" built-in with no
namespace. See the "package" entry in perlfunc for the details of empty
packages.



--------------------------------------------------------------------

The perlfaq-workers, a group of volunteers, maintain the perlfaq. They
are not necessarily experts in every domain where Perl might show up,
so please include as much information as possible and relevant in any
corrections. The perlfaq-workers also don't have access to every
operating system or platform, so please include relevant details for
corrections to examples that do not work on particular platforms.
Working code is greatly appreciated.

If you'd like to help maintain the perlfaq, see the details in
perlfaq.pod.
From: Ben Morrow on 21 Apr 2010 18:27

Quoth PerlFAQ Server <brian(a)theperlreview.com>:
>
> Most of the time, you shouldn't care what package an object is blessed
> into, however, as long as it claims to inherit from that class:
>
> my $is_right_class = eval { $object->isa( $package ) }; #
> true or false

Should this answer mention ->DOES at this point? AIUI, most of the time
it's a more appropriate test than ->isa, but I must admit I'm not
entirely clear on the difference between the two.

Ben

From: Xho Jingleheimerschmidt on 21 Apr 2010 22:25
Ben Morrow wrote:
> Quoth PerlFAQ Server <brian(a)theperlreview.com>:
>> Most of the time, you shouldn't care what package an object is blessed
>> into, however, as long as it claims to inherit from that class:
>>
>> my $is_right_class = eval { $object->isa( $package ) }; #
>> true or false
>
> Should this answer mention ->DOES at this point?

Where is that documented? I've heard of ->can, but never of ->DOES.

Is this a 5.10 thing?

And shouldn't there be an entry for "can" in perldoc -f? I know it
isn't strictly a function, but it is closer to one that "use" or "my".

Xho
From: brian d foy on 25 Apr 2010 16:43
In article <qma4a7-scj2.ln1(a)osiris.mauzo.dyndns.org>, Ben Morrow
<ben(a)morrow.me.uk> wrote:

> Quoth PerlFAQ Server <brian(a)theperlreview.com>:
> >
> > Most of the time, you shouldn't care what package an object is blessed
> > into, however, as long as it claims to inherit from that class:
> >
> > my $is_right_class = eval { $object->isa( $package ) }; #
> > true or false
>
> Should this answer mention ->DOES at this point? AIUI, most of the time
> it's a more appropriate test than ->isa, but I must admit I'm not
> entirely clear on the difference between the two.

Yes, that should be DOES now.

The difference between the two is that isa() checks for inheritance
while DOES() checks that the object performs a role despite
inheritance. Roles, traits, and mixins want to provide functionality
without inheritance.
From: Ben Morrow on 25 Apr 2010 18:08

Quoth brian d foy <brian.d.foy(a)gmail.com>:
> In article <qma4a7-scj2.ln1(a)osiris.mauzo.dyndns.org>, Ben Morrow
> <ben(a)morrow.me.uk> wrote:
> >
> > Should this answer mention ->DOES at this point? AIUI, most of the time
> > it's a more appropriate test than ->isa, but I must admit I'm not
> > entirely clear on the difference between the two.
>
> Yes, that should be DOES now.
>
> The difference between the two is that isa() checks for inheritance
> while DOES() checks that the object performs a role despite
> inheritance. Roles, traits, and mixins want to provide functionality
> without inheritance.

Yes, but when do you care? If an object conforms to a given interface,
what difference does it make (from outside the object) whether those
methods are implemented through inheritance, delegation, mixins, or
whatever?

Ben

 |  Next  |  Last
Pages: 1 2
Prev: Can not intercept and disable MouseWheel on a canvas
Next: How to ignore newline in Parse::RecDescent