hash::util::fieldhash.3

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

With \fIinside-out\fR classes, each class declares a (typically lexical)
hash for each field it wants to use.  The reference address of an
object is used as the hash key.  By definition, the reference address
is unique to each object so this guarantees a place for each field that
is private to the class and unique to each object.  See Name_id in
\&\*(L"Example 1\*(R" for a simple example.
.PP
In comparison to the standard implementation where the object is a
hash and the fields correspond to hash keys, here the fields correspond
to hashes, and the object determines the hash key.  Thus the hashes
appear to be turned \fIinside out\fR.
.PP
The body of an object is never examined by an inside-out class, only
its reference address is used.  This allows for the body of an actual
object to be \fIanything at all\fR while the object methods of the class
still work as designed.  This is a key feature of inside-out classes.
.Sh "Problems of Inside-out"
.IX Subsection "Problems of Inside-out"
Inside-out classes give us freedom of inheritance, but as usual there
is a price.
.PP
Most obviously, there is the necessity of retrieving the reference
address of an object for each data access.  It's a minor inconvenience,
but it does clutter the code.
.PP
More important (and less obvious) is the necessity of garbage
collection.  When a normal object dies, anything stored in the
object body is garbage-collected by perl.  With inside-out objects,
Perl knows nothing about the data stored in field hashes by a class,
but these must be deleted when the object goes out of scope.  Thus
the class must provide a \f(CW\*(C`DESTROY\*(C'\fR method to take care of that.
.PP
In the presence of multiple classes it can be non-trivial
to make sure that every relevant destructor is called for
every object.  Perl calls the first one it finds on the
inheritance tree (if any) and that's it.
.PP
A related issue is thread-safety.  When a new thread is created,
the Perl interpreter is cloned, which implies that all reference
addresses in use will be replaced with new ones.  Thus, if a class
tries to access a field of a cloned object its (cloned) data will
still be stored under the now invalid reference address of the
original in the parent thread.  A general \f(CW\*(C`CLONE\*(C'\fR method must
be provided to re-establish the association.
.Sh "Solutions"
.IX Subsection "Solutions"
\&\f(CW\*(C`Hash::Util::FieldHash\*(C'\fR addresses these issues on several
levels.
.PP
The \f(CW\*(C`id()\*(C'\fR function is provided in addition to the
existing \f(CW\*(C`Scalar::Util::refaddr()\*(C'\fR.  Besides its short name
it can be a little faster under some circumstances (and a
bit slower under others).  Benchmark if it matters.  The
working of \f(CW\*(C`id()\*(C'\fR also allows the use of the class name
as a \fIgeneric object\fR as described further down.
.PP
The \f(CW\*(C`id()\*(C'\fR function is incorporated in \fIid hashes\fR in the sense
that it is called automatically on every key that is used with
the hash.  No explicit call is necessary.
.PP
The problems of garbage collection and thread safety are both
addressed by the function \f(CW\*(C`register()\*(C'\fR.  It registers an object
together with any number of hashes.  Registry means that when the
object dies, an entry in any of the hashes under the reference
address of this object will be deleted.  This guarantees garbage
collection in these hashes.  It also means that on thread
cloning the object's entries in registered hashes will be
replaced with updated entries whose key is the cloned object's
reference address.  Thus the object-data association becomes
thread-safe.
.PP
Object registry is best done when the object is initialized
for use with a class.  That way, garbage collection and thread
safety are established for every object and every field that is
initialized.
.PP
Finally, \fIfield hashes\fR incorporate all these functions in one
package.  Besides automatically calling the \f(CW\*(C`id()\*(C'\fR function
on every object used as a key, the object is registered with
the field hash on first use.  Classes based on field hashes
are fully garbage-collected and thread safe without further
measures.
.Sh "More Problems"
.IX Subsection "More Problems"
Another problem that occurs with inside-out classes is serialization.
Since the object data is not in its usual place, standard routines
like \f(CW\*(C`Storable::freeze()\*(C'\fR, \f(CW\*(C`Storable::thaw()\*(C'\fR and 
\&\f(CW\*(C`Data::Dumper::Dumper()\*(C'\fR can't deal with it on their own.  Both
\&\f(CW\*(C`Data::Dumper\*(C'\fR and \f(CW\*(C`Storable\*(C'\fR provide the necessary hooks to
make things work, but the functions or methods used by the hooks
must be provided by each inside-out class.
.PP
A general solution to the serialization problem would require another
level of registry, one that that associates \fIclasses\fR and fields.
So far, the functions of \f(CW\*(C`Hash::Util::FieldHash\*(C'\fR are unaware of
any classes, which I consider a feature.  Therefore \f(CW\*(C`Hash::Util::FieldHash\*(C'\fR
doesn't address the serialization problems.
.Sh "The Generic Object"
.IX Subsection "The Generic Object"
Classes based on the \f(CW\*(C`id()\*(C'\fR function (and hence classes based on
\&\f(CW\*(C`idhash()\*(C'\fR and \f(CW\*(C`fieldhash()\*(C'\fR) show a peculiar behavior in that
the class name can be used like an object.  Specifically, methods
that set or read data associated with an object continue to work as
class methods, just as if the class name were an object, distinct from
all other objects, with its own data.  This object may be called
the \fIgeneric object\fR of the class.
.PP
This works because field hashes respond to keys that are not references
like a normal hash would and use the string offered as the hash key.
Thus, if a method is called as a class method, the field hash is presented
with the class name instead of an object and blithely uses it as a key.
Since the keys of real objects are decimal numbers, there is no
conflict and the slot in the field hash can be used like any other.
The \f(CW\*(C`id()\*(C'\fR function behaves correspondingly with respect to non-reference
arguments.
.PP
Two possible uses (besides ignoring the property) come to mind.
A singleton class could be implemented this using the generic object.
If necessary, an \f(CW\*(C`init()\*(C'\fR method could die or ignore calls with
actual objects (references), so only the generic object will ever exist.
.PP
Another use of the generic object would be as a template.  It is
a convenient place to store class-specific defaults for various
fields to be used in actual object initialization.
.PP
Usually, the feature can be entirely ignored.  Calling \fIobject
methods\fR as \fIclass methods\fR normally leads to an error and isn't used
routinely anywhere.  It may be a problem that this error isn't
indicated by a class with a generic object.
.Sh "How to use Field Hashes"
.IX Subsection "How to use Field Hashes"
Traditionally, the definition of an inside-out class contains a bare
block inside which a number of lexical hashes are declared and the
basic accessor methods defined, usually through \f(CW\*(C`Scalar::Util::refaddr\*(C'\fR.
Further methods may be defined outside this block.  There has to be
a \s-1DESTROY\s0 method and, for thread support, a \s-1CLONE\s0 method.
.PP
When field hashes are used, the basic structure remains the same.
Each lexical hash will be made a field hash.  The call to \f(CW\*(C`refaddr\*(C'\fR
can be omitted from the accessor methods.  \s-1DESTROY\s0 and \s-1CLONE\s0 methods
are not necessary.
.PP
If you have an existing inside-out class, simply making all hashes
field hashes with no other change should make no difference.  Through
the calls to \f(CW\*(C`refaddr\*(C'\fR or equivalent, the field hashes never get to
see a reference and work like normal hashes.  Your \s-1DESTROY\s0 (and
\&\s-1CLONE\s0) methods are still needed.
.PP
To make the field hashes kick in, it is easiest to redefine \f(CW\*(C`refaddr\*(C'\fR
as
.PP
.Vb 1
\&    sub refaddr { shift }
.Ve
.PP
instead of importing it from \f(CW\*(C`Scalar::Util\*(C'\fR.  It should now be possible
to disable \s-1DESTROY\s0 and \s-1CLONE\s0.  Note that while it isn't disabled,
\&\s-1DESTROY\s0 will be called before the garbage collection of field hashes,
so it will be invoked with a functional object and will continue to
function.
.PP
It is not desirable to import the functions \f(CW\*(C`fieldhash\*(C'\fR and/or
\&\f(CW\*(C`fieldhashes\*(C'\fR into every class that is going to use them.  They
are only used once to set up the class.  When the class is up and running,
these functions serve no more purpose.
.PP
If there are only a few field hashes to declare, it is simplest to
.PP
.Vb 1
\&    use Hash::Util::FieldHash;
.Ve
.PP
early and call the functions qualified:
.PP
.Vb 1
\&    Hash::Util::FieldHash::fieldhash my %foo;
.Ve
.PP
Otherwise, import the functions into a convenient package like
\&\f(CW\*(C`HUF\*(C'\fR or, more general, \f(CW\*(C`Aux\*(C'\fR
.PP
.Vb 4
\&    {
\&        package Aux;
\&        use Hash::Util::FieldHash \*(Aq:all\*(Aq;
\&    }
.Ve
.PP
and call
.PP
.Vb 1
\&    Aux::fieldhash my %foo;
.Ve
.PP
as needed.
.Sh "Garbage-Collected Hashes"
.IX Subsection "Garbage-Collected Hashes"
Garbage collection in a field hash means that entries will \*(L"spontaneously\*(R"
disappear when the object that created them disappears.  That must be
borne in mind, especially when looping over a field hash.  If anything
you do inside the loop could cause an object to go out of scope, a
random key may be deleted from the hash you are looping over.  That
can throw the loop iterator, so it's best to cache a consistent snapshot
of the keys and/or values and loop over that.  You will still have to
check that a cached entry still exists when you get to it.
.PP
Garbage collection can be confusing when keys are created in a field hash
from normal scalars as well as references.  Once a reference is \fIused\fR with
a field hash, the entry will be collected, even if it was later overwritten
with a plain scalar key (every positive integer is a candidate).  This
is true even if the original entry was deleted in the meantime.  In fact,
deletion from a field hash, and also a test for existence constitute
\&\fIuse\fR in this sense and create a liability to delete the entry when
the reference goes out of scope.  If you happen to create an entry
with an identical key from a string or integer, that will be collected
instead.  Thus, mixed use of references and plain scalars as field hash
keys is not entirely supported.
.SH "EXAMPLES"
.IX Header "EXAMPLES"
The examples show a very simple class that implements a \fIname\fR, consisting
of a first and last name (no middle initial).  The name class has four
methods:
.IP "\(bu" 4
\&\f(CW\*(C`init()\*(C'\fR
.Sp
An object method that initializes the first and last name to its
two arguments. If called as a class method, \f(CW\*(C`init()\*(C'\fR creates an
object in the given class and initializes that.
.IP "\(bu" 4
\&\f(CW\*(C`first()\*(C'\fR
.Sp
Retrieve the first name
.IP "\(bu" 4
\&\f(CW\*(C`last()\*(C'\fR
.Sp
Retrieve the last name
.IP "\(bu" 4
\&\f(CW\*(C`name()\*(C'\fR
.Sp
Retrieve the full name, the first and last name joined by a blank.
.PP
The examples show this class implemented with different levels of
support by \f(CW\*(C`Hash::Util::FieldHash\*(C'\fR.  All supported combinations
are shown.  The difference between implementations is often quite
small.  The implementations are:
.IP "\(bu" 4
\&\f(CW\*(C`Name_hash\*(C'\fR
.Sp
A conventional (not inside-out) implementation where an object is
a hash that stores the field values, without support by
\&\f(CW\*(C`Hash::Util::FieldHash\*(C'\fR.  This implementation doesn't allow
arbitrary inheritance.
.IP "\(bu" 4
\&\f(CW\*(C`Name_id\*(C'\fR
.Sp
Inside-out implementation based on the \f(CW\*(C`id()\*(C'\fR function.  It needs
a \f(CW\*(C`DESTROY\*(C'\fR method.  For thread support a \f(CW\*(C`CLONE\*(C'\fR method (not shown)
would also be needed.  Instead of \f(CW\*(C`Hash::Util::FieldHash::id()\*(C'\fR the
function \f(CW\*(C`Scalar::Util::refaddr\*(C'\fR could be used with very little
functional difference.  This is the basic pattern of an inside-out
class.
.IP "\(bu" 4
\&\f(CW\*(C`Name_idhash\*(C'\fR
.Sp
Idhash-based inside-out implementation.  Like Name_id it needs
a \f(CW\*(C`DESTROY\*(C'\fR method and would need \f(CW\*(C`CLONE\*(C'\fR for thread support.
.IP "\(bu" 4
\&\f(CW\*(C`Name_id_reg\*(C'\fR
.Sp
Inside-out implementation based on the \f(CW\*(C`id()\*(C'\fR function with explicit
object registry.  No destructor is needed and objects are thread safe.
.IP "\(bu" 4
\&\f(CW\*(C`Name_idhash_reg\*(C'\fR
.Sp
Idhash-based inside-out implementation with explicit object registry.
No destructor is needed and objects are thread safe.
.IP "\(bu" 4
\&\f(CW\*(C`Name_fieldhash\*(C'\fR
.Sp
FieldHash-based inside-out implementation.  Object registry happens
automatically.  No destructor is needed and objects are thread safe.
.PP
These examples are realized in the code below, which could be copied
to a file \fIExample.pm\fR.
.Sh "Example 1"
.IX Subsection "Example 1"
.Vb 1
\&    use strict; use warnings;
\&
\&    {
\&        package Name_hash; # standard implementation: the object is a hash
\&
\&        sub init {
\&            my $obj = shift;
\&            my ($first, $last) = @_;
\&            # create an object if called as class method
\&            $obj = bless {}, $obj unless ref $obj;
\&            $obj\->{ first} = $first;
\&            $obj\->{ last} = $last;
\&            $obj;
\&        }
\&
\&        sub first { shift()\->{ first} }
\&        sub last { shift()\->{ last} }
\&
\&        sub name {
\&            my $n = shift;
\&            join \*(Aq \*(Aq => $n\->first, $n\->last;
\&        }
\&
\&    }
\&
\&    {