[% setvar title Improve Perl Persistance %]
|Note: these documents may be out of date. Do not use as reference!|
To see what is currently happening visit http://www.perl6.org/
Improve Perl Persistance
Maintainer: Adam Turoff <email@example.com> Date: 24 Sep 2000 Last Modified: 30 Sep 2000 Mailing List: firstname.lastname@example.org Number: 287 Version: 2 Status: Frozen
Many mechanisms exist to make perl code and data persistant. They should be cleaned up, unified, and documented widely within the core documentation.
Tom Christiansen proposed this in his perl6storm message:
=item perl6storm #0022 make marshalling easy. core module? would this allow for easy persistence of data structures other than dbm files? general persistence is hard, right? can this be an attribute?
Python offers one way to make code/data persistant: the
More complex serialization can be accomplished through the 'shelve'
interface or DBM files. This capability is quite useful, widely known and
Perl, by comparison, offers Data::Dumper, which can serialize Perl objects
that are rather asymetrically reconstituted by using
Perl also offers solid, simple interfaces into DBM and Berkeley DB files,
and offer a well known, low-level serialization mechanism.
CPAN offers many other serialization modules that are only slightly different than Data::Dumper. This plethora of serialization mechanisms confuses users and adds to code bloat when multiple modules each use different serialization mechanisms that are all substantially similar.
Something similar to Python's
pickle interface should be added into Perl
as a builtin; this feature should have a symmetric "restore" builtin (eg
save()/restore(), freeze()/thaw(), dump()/undump()...).
Furthermore, Perl's low level serialization machinery (DBM, SDBM, GDBM, Berkeley DB) should be unified into a single core module, where the underlying DBM implementations are pluggable drivers, like DBI's DBD infrastructure.
First, the issue of adding builtin serialization functions needs to be addressed. This is a language issue because serialization should be more visible than it is today, and the best way to accomplish that is to include this feature as a pair of builtin functions.
If this feature is implemented through a core module, that module might best be presented as a pragmatic module.
Finally, although this proposal describes a simple matter of programming, some of the issues (such as pluggable interfaces) are best hashed out at a language-design level, so that they may be used elsewhere, easily.
Python Pocket Reference, Chapter 12