perltooc.pod

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

Even though we're using symbolic references for good not evil, some
folks tend to become unnerved when they see so many places with strict
ref checking disabled.  Given a symbolic reference, you can always
produce a real reference (the reverse is not true, though).  So we'll
create a subroutine that does this conversion for us.  If invoked as a
function of no arguments, it returns a reference to the compiling class's
eponymous hash.  Invoked as a class method, it returns a reference to
the eponymous hash of its caller.  And when invoked as an object method,
this function returns a reference to the eponymous hash for whatever
class the object belongs to.

    package Some_Class;
    use strict;

    our %Some_Class = (   	# our() is new to perl5.6
	CData1 => "",
	CData2 => "",
    );

    # tri-natured: function, class method, or object method
    sub _classobj {
	my $obclass = shift || __PACKAGE__;
	my $class   = ref($obclass) || $obclass;
	no strict "refs";   # to convert sym ref to real one
	return \%$class;
    } 

    for my $datum (keys %{ _classobj() } ) { 
	# turn off strict refs so that we can
	# register a method in the symbol table
	no strict "refs";    	
	*$datum = sub {
	    use strict "refs";
	    my $self = shift->_classobj();
	    $self->{$datum} = shift if @_;
	    return $self->{$datum};
	}
    }

=head2 Indirect References to Class Data

A reasonably common strategy for handling class attributes is to store
a reference to each package variable on the object itself.  This is
a strategy you've probably seen before, such as in L<perltoot> and
L<perlbot>, but there may be variations in the example below that you
haven't thought of before.

    package Some_Class;
    our($CData1, $CData2);      	# our() is new to perl5.6

    sub new {
	my $obclass = shift;
	return bless my $self = {
	    ObData1 => "",
	    ObData2 => "",
	    CData1  => \$CData1,
	    CData2  => \$CData2,
	} => (ref $obclass || $obclass);
    } 

    sub ObData1 {
	my $self = shift;
	$self->{ObData1} = shift if @_;
	return $self->{ObData1};
    } 

    sub ObData2 {
	my $self = shift;
	$self->{ObData2} = shift if @_;
	return $self->{ObData2};
    } 

    sub CData1 {
	my $self = shift;
	my $dataref = ref $self
			? $self->{CData1}
			: \$CData1;
	$$dataref = shift if @_;
	return $$dataref;
    } 

    sub CData2 {
	my $self = shift;
	my $dataref = ref $self
			? $self->{CData2}
			: \$CData2;
	$$dataref = shift if @_;
	return $$dataref;
    } 

As written above, a derived class will inherit these methods, which
will consequently access package variables in the base class's package.
This is not necessarily expected behavior in all circumstances.  Here's an
example that uses a variable meta-object, taking care to access the
proper package's data.

	package Some_Class;
	use strict;

	our %Some_Class = (   	# our() is new to perl5.6
	    CData1 => "",
	    CData2 => "",
	);

	sub _classobj {
	    my $self  = shift;
	    my $class = ref($self) || $self;
	    no strict "refs";
	    # get (hard) ref to eponymous meta-object
	    return \%$class;
	} 

	sub new {
	    my $obclass  = shift;
	    my $classobj = $obclass->_classobj();
	    bless my $self = {
		ObData1 => "",
		ObData2 => "",
		CData1  => \$classobj->{CData1},
		CData2  => \$classobj->{CData2},
	    } => (ref $obclass || $obclass);
	    return $self;
	} 

	sub ObData1 {
	    my $self = shift;
	    $self->{ObData1} = shift if @_;
	    return $self->{ObData1};
	} 

	sub ObData2 {
	    my $self = shift;
	    $self->{ObData2} = shift if @_;
	    return $self->{ObData2};
	} 

	sub CData1 {
	    my $self = shift;
	    $self = $self->_classobj() unless ref $self;
	    my $dataref = $self->{CData1};
	    $$dataref = shift if @_;
	    return $$dataref;
	} 

	sub CData2 {
	    my $self = shift;
	    $self = $self->_classobj() unless ref $self;
	    my $dataref = $self->{CData2};
	    $$dataref = shift if @_;
	    return $$dataref;
	} 

Not only are we now strict refs clean, using an eponymous meta-object
seems to make the code cleaner.  Unlike the previous version, this one
does something interesting in the face of inheritance: it accesses the
class meta-object in the invoking class instead of the one into which
the method was initially compiled.

You can easily access data in the class meta-object, making
it easy to dump the complete class state using an external mechanism such
as when debugging or implementing a persistent class.  This works because
the class meta-object is a package variable, has a well-known name, and
clusters all its data together.  (Transparent persistence
is not always feasible, but it's certainly an appealing idea.)

There's still no check that object accessor methods have not been
invoked on a class name.  If strict ref checking is enabled, you'd
blow up.  If not, then you get the eponymous meta-object.  What you do
with--or about--this is up to you.  The next two sections demonstrate
innovative uses for this powerful feature.

=head2 Monadic Classes

Some of the standard modules shipped with Perl provide class interfaces
without any attribute methods whatsoever.  The most commonly used module
not numbered amongst the pragmata, the Exporter module, is a class with
neither constructors nor attributes.  Its job is simply to provide a
standard interface for modules wishing to export part of their namespace
into that of their caller.  Modules use the Exporter's &import method by
setting their inheritance list in their package's @ISA array to mention
"Exporter".  But class Exporter provides no constructor, so you can't
have several instances of the class.  In fact, you can't have any--it
just doesn't make any sense.  All you get is its methods.  Its interface
contains no statefulness, so state data is wholly superfluous.

Another sort of class that pops up from time to time is one that supports
a unique instance.  Such classes are called I<monadic classes>, or less
formally, I<singletons> or I<highlander classes>.

If a class is monadic, where do you store its state, that is,
its attributes?  How do you make sure that there's never more than
one instance?  While you could merely use a slew of package variables,
it's a lot cleaner to use the eponymously named hash.  Here's a complete
example of a monadic class:

    package Cosmos;
    %Cosmos = ();

    # accessor method for "name" attribute
    sub name {
	my $self = shift;
	$self->{name} = shift if @_;
	return $self->{name};
    } 

    # read-only accessor method for "birthday" attribute
    sub birthday {
	my $self = shift;
	die "can't reset birthday" if @_;  # XXX: croak() is better
	return $self->{birthday};
    } 

    # accessor method for "stars" attribute
    sub stars {
	my $self = shift;
	$self->{stars} = shift if @_;
	return $self->{stars};
    } 

    # oh my - one of our stars just went out!
    sub supernova {
	my $self = shift;
	my $count = $self->stars();
	$self->stars($count - 1) if $count > 0;
    } 

    # constructor/initializer method - fix by reboot
    sub bigbang { 
	my $self = shift;
	%$self = (
	    name  	 => "the world according to tchrist",
	    birthday 	 => time(),
	    stars 	 => 0,
	);
	return $self;	    # yes, it's probably a class.  SURPRISE!
    }

    # After the class is compiled, but before any use or require 
    # returns, we start off the universe with a bang.  
    __PACKAGE__ -> bigbang();

Hold on, that doesn't look like anything special.  Those attribute
accessors look no different than they would if this were a regular class
instead of a monadic one.  The crux of the matter is there's nothing
that says that $self must hold a reference to a blessed object.  It merely
has to be something you can invoke methods on.  Here the package name
itself, Cosmos, works as an object.  Look at the &supernova method.  Is that
a class method or an object method?  The answer is that static analysis
cannot reveal the answer.  Perl doesn't care, and neither should you.
In the three attribute methods, C<%$self> is really accessing the %Cosmos
package variable.

If like Stephen Hawking, you posit the existence of multiple, sequential,
and unrelated universes, then you can invoke the &bigbang method yourself
at any time to start everything all over again.  You might think of
&bigbang as more of an initializer than a constructor, since the function
doesn't allocate new memory; it only initializes what's already there.
But like any other constructor, it does return a scalar value to use
for later method invocations.

Imagine that some day in the future, you decide that one universe just
isn't enough.  You could write a new class from scratch, but you already
have an existing class that does what you want--except that it's monadic,
and you want more than just one cosmos.

That's what code reuse via subclassing is all about.  Look how short
the new code is:

    package Multiverse;
    use Cosmos;
    @ISA = qw(Cosmos);

    sub new {
	my $protoverse = shift;
	my $class      = ref($protoverse) || $protoverse;
	my $self       = {};
	return bless($self, $class)->bigbang();
    } 
    1;

Because we were careful to be good little creators when we designed our
Cosmos class, we can now reuse it without touching a single line of code
when it comes time to write our Multiverse class.  The same code that
worked when invoked as a class method continues to work perfectly well
when invoked against separate instances of a derived class.

The astonishing thing about the Cosmos class above is that the value
returned by the &bigbang "constructor" is not a reference to a blessed
object at all.  It's just the class's own name.  A class name is, for
virtually all intents and purposes, a perfectly acceptable object.
It has state, behavior, and identity, the three crucial components
of an object system.  It even manifests inheritance, polymorphism,
and encapsulation.  And what more can you ask of an object?

To understand object orientation in Perl, it's important to recognize the
unification of what other programming languages might think of as class
methods and object methods into just plain methods.  "Class methods"
and "object methods" are distinct only in the compartmentalizing mind
of the Perl programmer, not in the Perl language itself.

Along those same lines, a constructor is nothing special either, which
is one reason why Perl has no pre-ordained name for them.  "Constructor"
is just an informal term loosely used to describe a method that returns
a scalar value that you can make further method calls against.  So long
as it's either a class name or an object reference, that's good enough.
It doesn't even have to be a reference to a brand new object.

You can have as many--or as few--constructors as you want, and you can
name them whatever you care to.  Blindly and obediently using new()
for each and every constructor you ever write is to speak Perl with
such a severe C++ accent that you do a disservice to both languages.
There's no reason to insist that each class have but one constructor,
or that a constructor be named new(), or that a constructor be
used solely as a class method and not an object method.

The next section shows how useful it can be to further distance ourselves
from any formal distinction between class method calls and object method
calls, both in constructors and in accessor methods.

=head2 Translucent Attributes

A package's eponymous hash can be used for more than just containing
per-class, global state data.  It can also serve as a sort of template
containing default settings for object attributes.  These default
settings can then be used in constructors for initialization of a
particular object.  The class's eponymous hash can also be used to
implement I<translucent attributes>.  A translucent attribute is one
that has a class-wide default.  Each object can set its own value for the
attribute, in which case C<< $object->attribute() >> returns that value.
But if no value has been set, then C<< $object->attribute() >> returns
the class-wide default.

We'll apply something of a copy-on-write approach to these translucent
attributes.  If you're just fetching values from them, you get
translucency.  But if you store a new value to them, that new value is
set on the current object.  On the other hand, if you use the class as