perlmod.1

视频监控网络部分的协议ddns,的模块的实现代码,请大家大胆指正.

\&  BEGIN { print " 2.   So this line comes out second.\en" }
\&  UNITCHECK {
\&   print " 3. UNITCHECK blocks run LIFO after each file is compiled.\en"
\&  }
\&  INIT { print  " 9.   You\*(Aqll see the difference right away.\en" }
\&
\&  print         "13.   It merely _looks_ like it should be confusing.\en";
\&
\&  _\|_END_\|_
.Ve
.Sh "Perl Classes"
.IX Xref "class @ISA"
.IX Subsection "Perl Classes"
There is no special class syntax in Perl, but a package may act
as a class if it provides subroutines to act as methods.  Such a
package may also derive some of its methods from another class (package)
by listing the other package name(s) in its global \f(CW@ISA\fR array (which
must be a package global, not a lexical).
.PP
For more on this, see perltoot and perlobj.
.Sh "Perl Modules"
.IX Xref "module"
.IX Subsection "Perl Modules"
A module is just a set of related functions in a library file, i.e.,
a Perl package with the same name as the file.  It is specifically
designed to be reusable by other modules or programs.  It may do this
by providing a mechanism for exporting some of its symbols into the
symbol table of any package using it, or it may function as a class
definition and make its semantics available implicitly through
method calls on the class and its objects, without explicitly
exporting anything.  Or it can do a little of both.
.PP
For example, to start a traditional, non-OO module called Some::Module,
create a file called \fISome/Module.pm\fR and start with this template:
.PP
.Vb 1
\&    package Some::Module;  # assumes Some/Module.pm
\&
\&    use strict;
\&    use warnings;
\&
\&    BEGIN {
\&        use Exporter   ();
\&        our ($VERSION, @ISA, @EXPORT, @EXPORT_OK, %EXPORT_TAGS);
\&
\&        # set the version for version checking
\&        $VERSION     = 1.00;
\&        # if using RCS/CVS, this may be preferred
\&        $VERSION = sprintf "%d.%03d", q$Revision: 1.1 $ =~ /(\ed+)/g;
\&
\&        @ISA         = qw(Exporter);
\&        @EXPORT      = qw(&func1 &func2 &func4);
\&        %EXPORT_TAGS = ( );     # eg: TAG => [ qw!name1 name2! ],
\&
\&        # your exported package globals go here,
\&        # as well as any optionally exported functions
\&        @EXPORT_OK   = qw($Var1 %Hashit &func3);
\&    }
\&    our @EXPORT_OK;
\&
\&    # exported package globals go here
\&    our $Var1;
\&    our %Hashit;
\&
\&    # non\-exported package globals go here
\&    our @more;
\&    our $stuff;
\&
\&    # initialize package globals, first exported ones
\&    $Var1   = \*(Aq\*(Aq;
\&    %Hashit = ();
\&
\&    # then the others (which are still accessible as $Some::Module::stuff)
\&    $stuff  = \*(Aq\*(Aq;
\&    @more   = ();
\&
\&    # all file\-scoped lexicals must be created before
\&    # the functions below that use them.
\&
\&    # file\-private lexicals go here
\&    my $priv_var    = \*(Aq\*(Aq;
\&    my %secret_hash = ();
\&
\&    # here\*(Aqs a file\-private function as a closure,
\&    # callable as &$priv_func;  it cannot be prototyped.
\&    my $priv_func = sub {
\&        # stuff goes here.
\&    };
\&
\&    # make all your functions, whether exported or not;
\&    # remember to put something interesting in the {} stubs
\&    sub func1      {}    # no prototype
\&    sub func2()    {}    # proto\*(Aqd void
\&    sub func3($$)  {}    # proto\*(Aqd to 2 scalars
\&
\&    # this one isn\*(Aqt exported, but could be called!
\&    sub func4(\e%)  {}    # proto\*(Aqd to 1 hash ref
\&
\&    END { }       # module clean\-up code here (global destructor)
\&
\&    ## YOUR CODE GOES HERE
\&
\&    1;  # don\*(Aqt forget to return a true value from the file
.Ve
.PP
Then go on to declare and use your variables in functions without
any qualifications.  See Exporter and the perlmodlib for
details on mechanics and style issues in module creation.
.PP
Perl modules are included into your program by saying
.PP
.Vb 1
\&    use Module;
.Ve
.PP
or
.PP
.Vb 1
\&    use Module LIST;
.Ve
.PP
This is exactly equivalent to
.PP
.Vb 1
\&    BEGIN { require Module; import Module; }
.Ve
.PP
or
.PP
.Vb 1
\&    BEGIN { require Module; import Module LIST; }
.Ve
.PP
As a special case
.PP
.Vb 1
\&    use Module ();
.Ve
.PP
is exactly equivalent to
.PP
.Vb 1
\&    BEGIN { require Module; }
.Ve
.PP
All Perl module files have the extension \fI.pm\fR.  The \f(CW\*(C`use\*(C'\fR operator
assumes this so you don't have to spell out "\fIModule.pm\fR" in quotes.
This also helps to differentiate new modules from old \fI.pl\fR and
\&\fI.ph\fR files.  Module names are also capitalized unless they're
functioning as pragmas; pragmas are in effect compiler directives,
and are sometimes called \*(L"pragmatic modules\*(R" (or even \*(L"pragmata\*(R"
if you're a classicist).
.PP
The two statements:
.PP
.Vb 2
\&    require SomeModule;
\&    require "SomeModule.pm";
.Ve
.PP
differ from each other in two ways.  In the first case, any double
colons in the module name, such as \f(CW\*(C`Some::Module\*(C'\fR, are translated
into your system's directory separator, usually \*(L"/\*(R".   The second
case does not, and would have to be specified literally.  The other
difference is that seeing the first \f(CW\*(C`require\*(C'\fR clues in the compiler
that uses of indirect object notation involving \*(L"SomeModule\*(R", as
in \f(CW\*(C`$ob = purge SomeModule\*(C'\fR, are method calls, not function calls.
(Yes, this really can make a difference.)
.PP
Because the \f(CW\*(C`use\*(C'\fR statement implies a \f(CW\*(C`BEGIN\*(C'\fR block, the importing
of semantics happens as soon as the \f(CW\*(C`use\*(C'\fR statement is compiled,
before the rest of the file is compiled.  This is how it is able
to function as a pragma mechanism, and also how modules are able to
declare subroutines that are then visible as list or unary operators for
the rest of the current file.  This will not work if you use \f(CW\*(C`require\*(C'\fR
instead of \f(CW\*(C`use\*(C'\fR.  With \f(CW\*(C`require\*(C'\fR you can get into this problem:
.PP
.Vb 2
\&    require Cwd;                # make Cwd:: accessible
\&    $here = Cwd::getcwd();
\&
\&    use Cwd;                    # import names from Cwd::
\&    $here = getcwd();
\&
\&    require Cwd;                # make Cwd:: accessible
\&    $here = getcwd();           # oops! no main::getcwd()
.Ve
.PP
In general, \f(CW\*(C`use Module ()\*(C'\fR is recommended over \f(CW\*(C`require Module\*(C'\fR,
because it determines module availability at compile time, not in the
middle of your program's execution.  An exception would be if two modules
each tried to \f(CW\*(C`use\*(C'\fR each other, and each also called a function from
that other module.  In that case, it's easy to use \f(CW\*(C`require\*(C'\fR instead.
.PP
Perl packages may be nested inside other package names, so we can have
package names containing \f(CW\*(C`::\*(C'\fR.  But if we used that package name
directly as a filename it would make for unwieldy or impossible
filenames on some systems.  Therefore, if a module's name is, say,
\&\f(CW\*(C`Text::Soundex\*(C'\fR, then its definition is actually found in the library
file \fIText/Soundex.pm\fR.
.PP
Perl modules always have a \fI.pm\fR file, but there may also be
dynamically linked executables (often ending in \fI.so\fR) or autoloaded
subroutine definitions (often ending in \fI.al\fR) associated with the
module.  If so, these will be entirely transparent to the user of
the module.  It is the responsibility of the \fI.pm\fR file to load
(or arrange to autoload) any additional functionality.  For example,
although the \s-1POSIX\s0 module happens to do both dynamic loading and
autoloading, the user can say just \f(CW\*(C`use POSIX\*(C'\fR to get it all.
.Sh "Making your module threadsafe"
.IX Xref "threadsafe thread safe module, threadsafe module, thread safe CLONE CLONE_SKIP thread threads ithread"
.IX Subsection "Making your module threadsafe"
Since 5.6.0, Perl has had support for a new type of threads called
interpreter threads (ithreads). These threads can be used explicitly
and implicitly.
.PP
Ithreads work by cloning the data tree so that no data is shared
between different threads. These threads can be used by using the \f(CW\*(C`threads\*(C'\fR
module or by doing \fIfork()\fR on win32 (fake \fIfork()\fR support). When a
thread is cloned all Perl data is cloned, however non-Perl data cannot
be cloned automatically.  Perl after 5.7.2 has support for the \f(CW\*(C`CLONE\*(C'\fR
special subroutine.  In \f(CW\*(C`CLONE\*(C'\fR you can do whatever
you need to do,
like for example handle the cloning of non-Perl data, if necessary.
\&\f(CW\*(C`CLONE\*(C'\fR will be called once as a class method for every package that has it
defined (or inherits it).  It will be called in the context of the new thread,
so all modifications are made in the new area.  Currently \s-1CLONE\s0 is called with
no parameters other than the invocant package name, but code should not assume
that this will remain unchanged, as it is likely that in future extra parameters
will be passed in to give more information about the state of cloning.
.PP
If you want to \s-1CLONE\s0 all objects you will need to keep track of them per
package. This is simply done using a hash and \fIScalar::Util::weaken()\fR.
.PP
Perl after 5.8.7 has support for the \f(CW\*(C`CLONE_SKIP\*(C'\fR special subroutine.
Like \f(CW\*(C`CLONE\*(C'\fR, \f(CW\*(C`CLONE_SKIP\*(C'\fR is called once per package; however, it is
called just before cloning starts, and in the context of the parent
thread. If it returns a true value, then no objects of that class will
be cloned; or rather, they will be copied as unblessed, undef values.
For example: if in the parent there are two references to a single blessed
hash, then in the child there will be two references to a single undefined
scalar value instead.
This provides a simple mechanism for making a module threadsafe; just add
\&\f(CW\*(C`sub CLONE_SKIP { 1 }\*(C'\fR at the top of the class, and \f(CW\*(C`DESTROY()\*(C'\fR will be
now only be called once per object. Of course, if the child thread needs
to make use of the objects, then a more sophisticated approach is
needed.
.PP
Like \f(CW\*(C`CLONE\*(C'\fR, \f(CW\*(C`CLONE_SKIP\*(C'\fR is currently called with no parameters other
than the invocant package name, although that may change. Similarly, to
allow for future expansion, the return value should be a single \f(CW0\fR or
\&\f(CW1\fR value.
.SH "SEE ALSO"
.IX Header "SEE ALSO"
See perlmodlib for general style issues related to building Perl
modules and classes, as well as descriptions of the standard library
and \s-1CPAN\s0, Exporter for how Perl's standard import/export mechanism
works, perltoot and perltooc for an in-depth tutorial on
creating classes, perlobj for a hard-core reference document on
objects, perlsub for an explanation of functions and scoping,
and perlxstut and perlguts for more information on writing
extension modules.