perltooc.1

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

.\" Automatically generated by Pod::Man 2.16 (Pod::Simple 3.05)
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sh \" Subsection heading
.br
.if t .Sp
.ne 5
.PP
\fB\\$1\fR
.PP
..
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings.  \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
.\" nothing in troff, for use with C<>.
.tr \(*W-
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
.    ds -- \(*W-
.    ds PI pi
.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
.    ds L" ""
.    ds R" ""
.    ds C` ""
.    ds C' ""
'br\}
.el\{\
.    ds -- \|\(em\|
.    ds PI \(*p
.    ds L" ``
.    ds R" ''
'br\}
.\"
.\" Escape single quotes in literal strings from groff's Unicode transform.
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
.\" entries marked with X<> in POD.  Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.ie \nF \{\
.    de IX
.    tm Index:\\$1\t\\n%\t"\\$2"
..
.    nr % 0
.    rr F
.\}
.el \{\
.    de IX
..
.\}
.\"
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
.\" Fear.  Run.  Save yourself.  No user-serviceable parts.
.    \" fudge factors for nroff and troff
.if n \{\
.    ds #H 0
.    ds #V .8m
.    ds #F .3m
.    ds #[ \f1
.    ds #] \fP
.\}
.if t \{\
.    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
.    ds #V .6m
.    ds #F 0
.    ds #[ \&
.    ds #] \&
.\}
.    \" simple accents for nroff and troff
.if n \{\
.    ds ' \&
.    ds ` \&
.    ds ^ \&
.    ds , \&
.    ds ~ ~
.    ds /
.\}
.if t \{\
.    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
.    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
.    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
.    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
.    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
.    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
.\}
.    \" troff and (daisy-wheel) nroff accents
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
.ds ae a\h'-(\w'a'u*4/10)'e
.ds Ae A\h'-(\w'A'u*4/10)'E
.    \" corrections for vroff
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
.    \" for low resolution devices (crt and lpr)
.if \n(.H>23 .if \n(.V>19 \
\{\
.    ds : e
.    ds 8 ss
.    ds o a
.    ds d- d\h'-1'\(ga
.    ds D- D\h'-1'\(hy
.    ds th \o'bp'
.    ds Th \o'LP'
.    ds ae ae
.    ds Ae AE
.\}
.rm #[ #] #H #V #F C
.\" ========================================================================
.\"
.IX Title "PERLTOOC 1"
.TH PERLTOOC 1 "2007-12-18" "perl v5.10.0" "Perl Programmers Reference Guide"
.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.if n .ad l
.nh
.SH "NAME"
perltooc \- Tom's OO Tutorial for Class Data in Perl
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
When designing an object class, you are sometimes faced with the situation
of wanting common state shared by all objects of that class.
Such \fIclass attributes\fR act somewhat like global variables for the entire
class, but unlike program-wide globals, class attributes have meaning only to
the class itself.
.PP
Here are a few examples where class attributes might come in handy:
.IP "\(bu" 4
to keep a count of the objects you've created, or how many are
still extant.
.IP "\(bu" 4
to extract the name or file descriptor for a logfile used by a debugging
method.
.IP "\(bu" 4
to access collective data, like the total amount of cash dispensed by
all ATMs in a network in a given day.
.IP "\(bu" 4
to access the last object created by a class, or the most accessed object,
or to retrieve a list of all objects.
.PP
Unlike a true global, class attributes should not be accessed directly.
Instead, their state should be inspected, and perhaps altered, only
through the mediated access of \fIclass methods\fR.  These class attributes
accessor methods are similar in spirit and function to accessors used
to manipulate the state of instance attributes on an object.  They provide a
clear firewall between interface and implementation.
.PP
You should allow access to class attributes through either the class
name or any object of that class.  If we assume that \f(CW$an_object\fR is of
type Some_Class, and the &Some_Class::population_count method accesses
class attributes, then these two invocations should both be possible,
and almost certainly equivalent.
.PP
.Vb 2
\&    Some_Class\->population_count()
\&    $an_object\->population_count()
.Ve
.PP
The question is, where do you store the state which that method accesses?
Unlike more restrictive languages like \*(C+, where these are called
static data members, Perl provides no syntactic mechanism to declare
class attributes, any more than it provides a syntactic mechanism to
declare instance attributes.  Perl provides the developer with a broad
set of powerful but flexible features that can be uniquely crafted to
the particular demands of the situation.
.PP
A class in Perl is typically implemented in a module.  A module consists
of two complementary feature sets: a package for interfacing with the
outside world, and a lexical file scope for privacy.  Either of these
two mechanisms can be used to implement class attributes.  That means you
get to decide whether to put your class attributes in package variables
or to put them in lexical variables.
.PP
And those aren't the only decisions to make.  If you choose to use package
variables, you can make your class attribute accessor methods either ignorant
of inheritance or sensitive to it.  If you choose lexical variables,
you can elect to permit access to them from anywhere in the entire file
scope, or you can limit direct data access exclusively to the methods
implementing those attributes.
.SH "Class Data in a Can"
.IX Header "Class Data in a Can"
One of the easiest ways to solve a hard problem is to let someone else
do it for you!  In this case, Class::Data::Inheritable (available on a
\&\s-1CPAN\s0 near you) offers a canned solution to the class data problem
using closures.  So before you wade into this document, consider
having a look at that module.
.SH "Class Data as Package Variables"
.IX Header "Class Data as Package Variables"
Because a class in Perl is really just a package, using package variables
to hold class attributes is the most natural choice.  This makes it simple
for each class to have its own class attributes.  Let's say you have a class
called Some_Class that needs a couple of different attributes that you'd
like to be global to the entire class.  The simplest thing to do is to
use package variables like \f(CW$Some_Class::CData1\fR and \f(CW$Some_Class::CData2\fR
to hold these attributes.  But we certainly don't want to encourage
outsiders to touch those data directly, so we provide methods
to mediate access.
.PP
In the accessor methods below, we'll for now just ignore the first
argument\*(--that part to the left of the arrow on method invocation, which 
is either a class name or an object reference.
.PP
.Vb 11
\&    package Some_Class;
\&    sub CData1 {
\&        shift;  # XXX: ignore calling class/object
\&        $Some_Class::CData1 = shift if @_;
\&        return $Some_Class::CData1;
\&    } 
\&    sub CData2 {
\&        shift;  # XXX: ignore calling class/object
\&        $Some_Class::CData2 = shift if @_;
\&        return $Some_Class::CData2;
\&    }
.Ve
.PP
This technique is highly legible and should be completely straightforward
to even the novice Perl programmer.  By fully qualifying the package
variables, they stand out clearly when reading the code.  Unfortunately,
if you misspell one of these, you've introduced an error that's hard
to catch.  It's also somewhat disconcerting to see the class name itself
hard-coded in so many places.
.PP
Both these problems can be easily fixed.  Just add the \f(CW\*(C`use strict\*(C'\fR
pragma, then pre-declare your package variables.  (The \f(CW\*(C`our\*(C'\fR operator
will be new in 5.6, and will work for package globals just like \f(CW\*(C`my\*(C'\fR
works for scoped lexicals.)
.PP
.Vb 10
\&    package Some_Class;
\&    use strict;
\&    our($CData1, $CData2);      # our() is new to perl5.6
\&    sub CData1 {
\&        shift;  # XXX: ignore calling class/object
\&        $CData1 = shift if @_;
\&        return $CData1;
\&    } 
\&    sub CData2 {
\&        shift;  # XXX: ignore calling class/object
\&        $CData2 = shift if @_;
\&        return $CData2;
\&    }
.Ve
.PP
As with any other global variable, some programmers prefer to start their
package variables with capital letters.  This helps clarity somewhat, but
by no longer fully qualifying the package variables, their significance
can be lost when reading the code.  You can fix this easily enough by
choosing better names than were used here.
.Sh "Putting All Your Eggs in One Basket"
.IX Subsection "Putting All Your Eggs in One Basket"
Just as the mindless enumeration of accessor methods for instance attributes
grows tedious after the first few (see perltoot), so too does the
repetition begin to grate when listing out accessor methods for class
data.  Repetition runs counter to the primary virtue of a programmer:
Laziness, here manifesting as that innate urge every programmer feels
to factor out duplicate code whenever possible.
.PP
Here's what to do.  First, make just one hash to hold all class attributes.
.PP
.Vb 6
\&    package Some_Class;
\&    use strict;
\&    our %ClassData = (          # our() is new to perl5.6
\&        CData1 => "",
\&        CData2 => "",
\&    );
.Ve
.PP
Using closures (see perlref) and direct access to the package symbol
table (see perlmod), now clone an accessor method for each key in
the \f(CW%ClassData\fR hash.  Each of these methods is used to fetch or store
values to the specific, named class attribute.
.PP
.Vb 8
\&    for my $datum (keys %ClassData) {
\&        no strict "refs";       # to register new methods in package
\&        *$datum = sub {
\&            shift;      # XXX: ignore calling class/object
\&            $ClassData{$datum} = shift if @_;
\&            return $ClassData{$datum};
\&        } 
\&    }
.Ve
.PP
It's true that you could work out a solution employing an &AUTOLOAD
method, but this approach is unlikely to prove satisfactory.  Your
function would have to distinguish between class attributes and object
attributes; it could interfere with inheritance; and it would have to
careful about \s-1DESTROY\s0.  Such complexity is uncalled for in most cases,
and certainly in this one.
.PP
You may wonder why we're rescinding strict refs for the loop.  We're
manipulating the package's symbol table to introduce new function names
using symbolic references (indirect naming), which the strict pragma
would otherwise forbid.  Normally, symbolic references are a dodgy
notion at best.  This isn't just because they can be used accidentally
when you aren't meaning to.  It's also because for most uses
to which beginning Perl programmers attempt to put symbolic references,
we have much better approaches, like nested hashes or hashes of arrays.
But there's nothing wrong with using symbolic references to manipulate
something that is meaningful only from the perspective of the package
symbol table, like method names or package variables.  In other
words, when you want to refer to the symbol table, use symbol references.
.PP
Clustering all the class attributes in one place has several advantages.
They're easy to spot, initialize, and change.  The aggregation also
makes them convenient to access externally, such as from a debugger
or a persistence package.  The only possible problem is that we don't
automatically know the name of each class's class object, should it have
one.  This issue is addressed below in \*(L"The Eponymous Meta-Object\*(R".
.Sh "Inheritance Concerns"
.IX Subsection "Inheritance Concerns"
Suppose you have an instance of a derived class, and you access class
data using an inherited method call.  Should that end up referring
to the base class's attributes, or to those in the derived class?
How would it work in the earlier examples?  The derived class inherits
all the base class's methods, including those that access class attributes.
But what package are the class attributes stored in?
.PP
The answer is that, as written, class attributes are stored in the package into
which those methods were compiled.  When you invoke the &CData1 method
on the name of the derived class or on one of that class's objects, the
version shown above is still run, so you'll access \f(CW$Some_Class::CData1\fR\-\-or
in the method cloning version, \f(CW$Some_Class::ClassData{CData1}\fR.
.PP
Think of these class methods as executing in the context of their base
class, not in that of their derived class.  Sometimes this is exactly
what you want.  If Feline subclasses Carnivore, then the population of
Carnivores in the world should go up when a new Feline is born.
But what if you wanted to figure out how many Felines you have apart
from Carnivores?  The current approach doesn't support that.
.PP
You'll have to decide on a case-by-case basis whether it makes any sense
for class attributes to be package-relative.  If you want it to be so,
then stop ignoring the first argument to the function.  Either it will
be a package name if the method was invoked directly on a class name,
or else it will be an object reference if the method was invoked on an
object reference.  In the latter case, the \fIref()\fR function provides the
class of that object.
.PP
.Vb 9
\&    package Some_Class;
\&    sub CData1 {
\&        my $obclass = shift;    
\&        my $class   = ref($obclass) || $obclass;
\&        my $varname = $class . "::CData1";
\&        no strict "refs";       # to access package data symbolically
\&        $$varname = shift if @_;
\&        return $$varname;
\&    }
.Ve
.PP
And then do likewise for all other class attributes (such as CData2,
etc.) that you wish to access as package variables in the invoking package
instead of the compiling package as we had previously.