A
Anno Siegel
As of v5.10 Perl will provide support for inside-out classes in form of
a new core module Hash::Util::FieldHash. It is already available in the
current bleadperl.
Inside-out classes store object data in hashes keyed by the object. That
way each field of a class is realized as one lexical hash which may thus
be called a field hash.
Normal hashes have a number of disadvantages in this approach. For one,
references are stringified when used as hash keys, but the stringification
depends on the bless status of the reference. After a re-bless of an
object, its data would be lost (not to mention overloaded stringification).
This is usually corrected by calling the function Scalar::Util::Refaddr
(or some equivalent) before a refrerence is used as a hash key.
Another problem is that hash entries don't go away when objects go out
of scope. This leads to an obvious memory leak. Even worse, objects
are re-used by the perl interpreter, and if the field hashes aren't
cleaned up, a new object may accidentally access data that had been
used by its earlier incarnation. So an inside-out class based on
standard hashes *must* have a DESTROY method which needs some infra-
structure to work.
A third problem is threads. When a new thread is created, the entire
perl interpreter is cloned. That means that in the new thread all
variables will have new reference addresses. So objects will lose
their data across threads, unless the class has a CLONE method to
correct that. It turns out that CLONE needs much the same infra-
structure as garbage collection.
With Hash::Util::FieldHash you can declare a new type of hash that
takes care of these problems. The stringification of keys as their
decimal reference address is built into these hashes. Furthermore,
field hashes are garbage-collected and thread-safe so that a class
built with field hashes can safely run without DESTROY and
CLONE methods. That simplifies the construction considerably.
The documentation of Hash::Util::FieldHash can be seen at
http://www.tu-berlin.de/zrz/mitarbeiter/anno4000/clpm/FieldHash.html
Inside-out classes have a fourth problem, which is serialization
and persistence. Tools like Data:
umper and Storable don't save,
restore or show the data of an inside-out object, they know nothing
about that. Hash::Util::FieldHash doesn't address this problem.
I am planning a (non-core) module for CPAN, probably Class::Field
(based on FieldHash) that makes inside-out classes that are constructed
with it viewable, dumpable and restorable.
Anno
a new core module Hash::Util::FieldHash. It is already available in the
current bleadperl.
Inside-out classes store object data in hashes keyed by the object. That
way each field of a class is realized as one lexical hash which may thus
be called a field hash.
Normal hashes have a number of disadvantages in this approach. For one,
references are stringified when used as hash keys, but the stringification
depends on the bless status of the reference. After a re-bless of an
object, its data would be lost (not to mention overloaded stringification).
This is usually corrected by calling the function Scalar::Util::Refaddr
(or some equivalent) before a refrerence is used as a hash key.
Another problem is that hash entries don't go away when objects go out
of scope. This leads to an obvious memory leak. Even worse, objects
are re-used by the perl interpreter, and if the field hashes aren't
cleaned up, a new object may accidentally access data that had been
used by its earlier incarnation. So an inside-out class based on
standard hashes *must* have a DESTROY method which needs some infra-
structure to work.
A third problem is threads. When a new thread is created, the entire
perl interpreter is cloned. That means that in the new thread all
variables will have new reference addresses. So objects will lose
their data across threads, unless the class has a CLONE method to
correct that. It turns out that CLONE needs much the same infra-
structure as garbage collection.
With Hash::Util::FieldHash you can declare a new type of hash that
takes care of these problems. The stringification of keys as their
decimal reference address is built into these hashes. Furthermore,
field hashes are garbage-collected and thread-safe so that a class
built with field hashes can safely run without DESTROY and
CLONE methods. That simplifies the construction considerably.
The documentation of Hash::Util::FieldHash can be seen at
http://www.tu-berlin.de/zrz/mitarbeiter/anno4000/clpm/FieldHash.html
Inside-out classes have a fourth problem, which is serialization
and persistence. Tools like Data:
umper and Storable don't save,restore or show the data of an inside-out object, they know nothing
about that. Hash::Util::FieldHash doesn't address this problem.
I am planning a (non-core) module for CPAN, probably Class::Field
(based on FieldHash) that makes inside-out classes that are constructed
with it viewable, dumpable and restorable.
Anno