Learning Perl Objects, References amp;amp; Modules [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Learning Perl Objects, References amp;amp; Modules [Electronic resources] - نسخه متنی

Randal L. Schwartz

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید














12.10 Exporting in a Primarily OO Module


As
seen earlier, the normal means of using an object-oriented module is
to call class methods and then methods against instances resulting
from constructors of that class. This means that an OO module
typically exports nothing, so you'll have:

package My::OOModule::Base;
our @EXPORT = ( ); # you may even omit this line
use Exporter;
our @ISA = qw(Exporter);

As stated in Chapter 8, you can even shorten this
down:

package My::OOModule::Base;
use base qw(Exporter);

What if you then derive a class from this
base class? The most important thing to remember is that the
import method must be defined from the
Exporter class, so you add it like so:

package My::OOModule::Derived;
use base qw(Exporter My::OOModule::Base);

However, wouldn't the call to
My::OOModule::Derived->import eventually find
its way up to Exporter via
My::OOModule::Base? Sure it would. So you can
leave that out:

package My::OOModule::Derived;
use base qw(My::OOModule::Base);

Only the base classes at the top of the tree need specify
Exporter and only when they derive from no other
classes.

Please be aware of all the
other reserved method names that can't be used by
your OO module (as described in the Exporter
manpage). At the time of this writing, the list is
export_to_level,
require_version, and
export_fail. Also, you may wish to reserve
unimport because that routine will be called by
replacing use with no. That use
is rare for user-written modules, however.

Even though an OO module typically exports nothing, you might choose
to export a named constructor or management routine. This routine
typically acts a bit like a class method but is meant to be called as
a normal routine.

One example can be found
in the LWP library (on the CPAN). The
URI::URL module (now deprecated and replaced by
the URI module) deals with universal resource
identifiers, most commonly seen as URLs such as
http://www.gilligan.crew.hut/maps/island.pdf.
You can construct a URI::URL object as a
traditional object constructor with:

use URI::URL;
my $u = URI::URL->new("http://www.gilligan.crew.hut/maps/island.pdf");

The default import list for
URI::URL also imports a url
subroutine, which can be used as a constructor as well:

use URI::URL;
my $u = url("http://www.gilligan.crew.hut/maps/island.pdf");

Because this imported routine isn't a class method,
you don't use the arrow method call to invoke it.
Also, the routine is unlike anything else in the module: no initial
class parameter is passed. Even though normal subroutines and method
calls are both defined as subroutines in the package, the caller and
the author must agree as to which is which.

The url convenience routine was nice, initially.
However, it also clashed with the same-name routine in
CGI.pm, leading to interesting errors (especially
in a mod_perl setting). (The modern interface in
the URI module doesn't export
such a constructor.) Prior to that, in order to prevent a crash, you
had to remember to bring it in as:

use URI::URL (  );        # don't import "url"
my $u = URI::URL->new(...);



/ 199