Free object serialization software for linux

Object::Transaction is a virtual base class for transactions on files containing serialized hash objects.

SYNOPSIS

use Object::Transaction;

transaction($coderef, @codeargs);
commit();
abandon();
$there_is_a_pending_transaction = transaction_pending()

package Pkg;

@ISA = qw(Object::Transaction);

use Object::Transaction;

$obj = sub new { ... }
sub file($ref,$id) { ... }

$obj = load Pkg $id;
$obj->savelater();
$obj->save();
$obj->removelater();
$obj->remove();
$obj->commit();
$obj->uncache();
$obj->abandon();
$oldobj = $obj->old();

$reference = $obj->objectref();
$obj = $reference->loadref();

$id = sub id { ... }
$restart_commit = sub precommit() { }
@passby = sub presave($old) { ... }
sub postsave($old,@passby) { ... }
$newid = sub preload($id) { .... }
sub postload() { ... }
sub preremove() { ... }
sub postremove() { ... }

Object::Transaction provides transaction support for hash-based objects that are stored one-per-file using Storable. Multiuser access is supported. In the future, serializing methods other than Storable will be supported.

Object::Transaction is a virtual base class. In order to use it, you must inherit from it and override the new method and the file method.

Optomistic locking is used: it is possible that a transaction will fail because the data that is is based upon has changed out from under it.

Object::Realize::Later is a Perl module with delayed creation of objects.

SYNOPSIS

package MyLazyObject;

use Object::Realize::Later
becomes => MyRealObject,
realize => load;

The Object::Realize::Later class helps with implementing transparent on demand realization of object data. This is related to the tricks on autoloading of data, the lesser known cousin of autoloading of functionality.

On demand realization is all about performance gain. Why should you spent costly time on realizing an object, when the data on the object is never (or not yet) used? In interactive programs, postponed realization may boost start-up: the realization of objects is triggered by the use, so spread over time.

METHODS

Construction

use(Object::Realize::Later OPTIONS)

When you invoke (use) the Object::Realize::Later package, it will add a set of methods to your package (see section "Added to YOUR class").

Option --Default
becomes < required >
believe_caller < false >
realize < required >
source_module < becomes >
warn_realization < false >
warn_realize_again < false >
. becomes CLASS

Which type will this object become after realization.

. believe_caller BOOLEAN

When a method is called on the un-realized object, the AUTOLOAD checks whether this resolves the need. If not, the realization is not done. However, when realization may result in an object that extends the functionality of the class specified with becomes, this check must be disabled. In that case, specify true for this option.

. realize METHOD|CODE

How will transform. If you specify a CODE reference, then this will be called with the lazy-object as first argument, and the requested method as second.
After realization, you may still have your hands on the lazy object on various places. Be sure that your realization method is coping with that, for instance by using Memoize. See examples below.

. source_module CLASS

if the class (a package) is included in a file (module) with a different name, then use this argument to specify the file name. The name is expected to be the same as in the require call which would load it.

. warn_realization BOOLEAN

Print a warning message when the realization starts. This is for debugging purposes.

. warn_realize_again BOOLEAN

When an object is realized, the original object -which functioned as a stub- is reconstructed to work as proxy to the realized object. This option will issue a warning when that proxy is used, which means that somewhere in your program there is a variable still holding a reference to the stub. This latter is not problematic at all, although it slows-down each method call.

Added to YOUR class

$obj->AUTOLOAD

When a method is called which is not available for the lazy object, the AUTOLOAD is called.

$obj->can(METHOD)

Object::Realize::Later->can(METHOD)

Is the specified METHOD available for the lazy or the realized version of this object? It will return the reference to the code.

Example:

MyLazyObject->can(lazyWork) # true
MyLazyObject->can(realWork) # true

my $lazy = MyLazyObject->new;
$lazy->can(lazyWork); # true
$lazy->can(realWork); # true
$obj->forceRealize

You can force the load by calling this method on your object. It returns the realized object.

Object::Realize::Later->isa(CLASS)

Is this object a (sub-)class of the specified CLASS or can it become a (sub-)class of CLASS.

Example:

MyLazyObject->isa(MyRealObject) # true
MyLazyObject->isa(SuperClassOfLazy); # true
MyLazyObject->isa(SuperClassOfReal); # true

my $lazy = MyLazyObject->new;
$lazy->isa(MyRealObject); # true
$lazy->isa(SuperClassOfLazy); # true
$lazy->isa(SuperClassOfReal); # true
$obj->willRealize

Returns which class will be the realized to follow-up this class.

Object::Realize::Later internals

The next methods are not exported to the class where the `use took place. These methods implement the actual realization.

Object::Realize::Later->import(OPTIONS)

The OPTIONS used for import are the values after the class name with use. So this routine implements the actual option parsing. It generates code dynamically, which is then evaluated in the callers name-space.

Object::Realize::Later->realizationOf(OBJECT [,REALIZED])

Returns the REALIZED version of OBJECT, optionally after setting it first. When the method returns undef, the realization has not yet taken place or the realized object has already been removed again.

Object::Realize::Later->realize(OPTIONS)

This method is called when a $object-forceRealize()> takes place. It checks whether the realization has been done already (is which case the realized object is returned)

Object::Mediator is a generic object persistence framework.

SYNOPSIS

package Persistent;

use base qw( Object::Mediator );

__PACKAGE__->mk_attr ( qw(foo bar) );

sub _set_id {
my $self = shift;

my $id = generate_identity();

$self->identity( $id );
}

sub _insert {
my $self = shift;

$db_handle->insert ( $self->id, $self->foo, $self->bar );
}

sub _update {
my $self = shift;

$db_handle->update ( $self );
}

sub _delete {
my $self = shift;

$db_handle->delete ( $self->id );
}

sub _select {
my $self = shift;

my ( $foo, $bar ) = $db_handle->select ( $self->id );

$self->foo ( $foo );
$self->bar ( $bar );
}

Object::Mediator attempts to be simple and fairly minimalistic object mapping framework. Main aims of development were: usage simplicity, end user transparency, database independency and minimization of database interaction with some kind of in-memory object state control system.

Object::PerlDesignPatterns is a Perl architecture for structuring and refactoring large programs.

SYNOPSIS

lynx perldesignpatterns.html
perldoc Object::PerlDesignPatterns

ABSTRACT

Documentation: Ideas for keeping programs fun to hack on even after they grow large. Object, lambda, hybrid structures, Perl specific methods of refactoring, object tricks, anti-patterns, non-structural recurring code patterns.

PerlDesignPatterns is a free book sporting:

Ideas for keeping programs fun to hack on even after they grow large. Object, lambda, hybrid structures, Perl specific methods of refactoring, object tricks, anti-patterns, non-structural recurring code patterns.

Feel free to jump right in and make corrections, suggestions, ask questions, play editor, or just rant. Start in http://www.perldesignpatterns.com/?TinyWiki to learn about the TinyWiki software, make a page for yourself, play with editing that, perhaps make a link from the GuestLog to your page. The markup language is ASCII based - it couldnt be any easier.

This document is a snapshot of the current state of the Wiki, automatically compiled from hundreds of individual sections by a Perl script.

Object::Relation::Meta::Type is an Object::Relation Data type validation and accessor building.

Synopsis

Object::Relation::Meta::Type->add(
key => "state",
name => "State",
builder => Object::Relation::Meta::AccessorBuilder,
raw => sub { ref $_[0] ? shift->value : shift },
store_raw => sub { shift->store_value },
check => sub {
UNIVERSAL::isa($_[0], Object::Relation::DataType::State)
or throw_invalid([Value "[_1]" is not a valid [_2] object,
$_[0], Object::Relation::DataType::State]);
throw_invalid([Cannot assign permanent state])
if $_[0] == Object::Relation::DataType::State->PERMANENT;
}
);

This class subclasses Class::Meta::Type to provide additional attributes. These attributes can optionally be set via the call to new(), and may be fetched via their accessors.

Object Extensions for PHP provides several classes that add runtime object extension and callbacks to the language. Object Extensions for PHP allows the programmer to add methods and properties to an object at runtime by dynamically extending by another object.

It also allows the creation of object property lists that allow for dynamic setting/getting of values in a fashion similar to JavaScript objects. These object property lists support basic value checking.

The Object Extensions library for PHP adds the following functionality to objects that extend the base class:

- Runtime object extension to "extend" an object by another class at runtime (to virtually inherit all public properties and methods).
- Runtime callback definitions to be able to pass function/method callbacks as variables, and subsequently execute them from other function/methods.
- Dynamic object properties class to handle runtime setting/getting of object properties, as well as ability to pass function arguments as object-based parameters rather than long list of options.

OBJECT EXTENSION:

- Base class (CExtendable) implements a _extend() function by which you may vritually extend an object by an instance of another object.
- Extended object (object passed to _extend) can reference parent object if supported by extended class.
- __get, __set and __call are all overriden to handle overriding undefined properties and methods
- Ability to reference a callback in a straightforward manner ($object->_callback()->method(args, [...]))

CALLBACK FUNCTIONALITY:

- Can create callbacks directly (through CCallback and derived classes)
- Can create method callbacks by calling _callback() method on CExtendable objects
- When combined with object extension and object properties, can provide a really easy way to execute callbacks.

OBJECT PROPERTIES:

- Base class extends ArrayIterator, all properties saved in an array
- Basic functionality to check values provided and/or set default values.
- Overrides __get, __set to get/set object properties.
- Can limit property set-tability to existing properties only, or to provided array of properties.
- Can enable read-only mode.
- Overrides __call, and in the case that the a property value with the same name as the method name exists, and is an instance of the ICallback interface, this callback is executed.

PHP COMPATIBILITY:

Object Extensions for PHP uses PHP5 functionality. It would be theoretically possible to implement similar functionality into PHP4, however, since I no longer develop in PHP4, I cannot properly test it.

Basset::Object::Persistent is a subclass of Basset::Object that allows objects to be easily stored into a relational database. Presently only supports MySQL, but that may change in the future.

SYNOPSIS

(no synopsis, this is an abstract super class that should never be instantiated directly, it should be subclassed for all persistent objects and used through them)

Basset::Object is the uber module in my Perl world. All objects should decend from Basset::Object. It handles defining attributes, error handling, construction, destruction, and generic initialization. It also talks to Basset::Object::Conf to allow conf file use.
But, some objects cannot simply be recreated constantly every time a script runs. Sometimes you need to store the data in an object between uses so that you can recreate an object in the same form the last time you left it. Storing user information, for instance.

Basset::Object::Persistent allows you to do that transparently and easily. Persistent objects need to define several pieces of additional information to allow them to commit to the database, including their table definitions. Once these items are defined, youll have access to the load and commit methods to allow you to load and store the objects in a database.

It is assumed that an object is stored in the database in a primary table. The primary table contains a set of columns named the same as object attributes. The attributes are stored in those columns.

Some::Package->add_attr(foo);
my $obj = Some::Package->new();
$obj->foo(bar);
$obj->commit();

in the database, the foo column will be set to bar.