NAME
Hash::Objectify - Create objects from hashes on the fly
VERSION
version 0.008
SYNOPSIS
use Hash::Objectify;
# turn a hash reference into an object with accessors
$object = objectify { foo => 'bar', wibble => 'wobble' };
print $object->foo;
# objectify with a specific class name
$object = objectify { foo => 'bar' }, "Foo::Response";
print ref $object; # "Foo::Response"
DESCRIPTION
Hash::Objectify turns a hash reference into a simple object with
accessors for each of the keys.
One application of this module could be to create lightweight response
objects without the extra work of setting up an entire response class
with the framework of your choice.
Using Hash::Objectify is slower than accessing the keys of the hash
directly, but does provide "typo protection" since a misspelled method
is an error.
USAGE
By default, the "objectify" function is automatically exported.
objectify
$object = objectify $hashref
$object = objectify $hashref, $classname;
$object->$key; # accessor
$object->$key($value); # mutator
The "objectify" function copies the hash reference (shallow copy), and
blesses it into the given classname. If no classname is given, a
meaningless, generated package name is used instead. In either case, the
object will inherit from the Hash::Objectified class, which generates
accessors on demand for any key in the hash.
As an optimization, a generated classname will be the same for any given
"objectify" call if the keys of the input are the same. (This avoids
excessive accessor generation.)
The first time a method is called on the object, an accessor will be
dynamically generated if the key exists. If the key does not exist, an
exception is thrown. Note: deleting a key *after* calling it as an
accessor will not cause subsequent calls to throw an exception; the
accessor will merely return undef.
Objectifying with a "real" classname that does anything other than
inherit from Hash::Objectified may lead to surprising behaviors from
method name conflict. You probably don't want to do that.
Objectifying anything other than an unblessed hash reference is an
error. This is true even for objects based on blessed hash references,
since the correct semantics are not universally obvious. If you really
want Hash::Objectify for access to the keys of a blessed hash, you
should make an explicit, shallow copy:
my $copy = objectify {%$object};
objectify_lax
$object = objectify_lax { foo => 'bar' };
$object->quux; # not fatal
This works just like "objectify", except that non-existing keys return
"undef" instead of throwing exceptions. Non-existing keys will still
return "undef" if checked with "can".
WARNING: having an object that doesn't throw on unknown methods violates
object-oriented behavior expectations so is generally a bad idea. If you
really feel you need this, be aware that the safety guard is removed and
you might lose a finger.
If called with an existing non-lax objectified package name, the
behavior of accessors not yet called with change to become lax. You
probably don't want to do that.
CAVEATS
If an objectified hashref contains keys that conflict with existing
resolvable methods (e.g. "can", "AUTOLOAD", "DESTROY"), you won't be
able to access those keys via a method as the existing methods take
precedence.
Specifying custom package names or manipulating @ISA for objectified
packages (including subclassing) is likely to lead to surprising
behavior. It is not recommended and is not supported. If it breaks, you
get to keep the pieces.
SUPPORT
Bugs / Feature Requests
Please report any bugs or feature requests through the issue tracker at
notified automatically of any progress on your issue.
Source Code
This is open source software. The code repository is available for
public review and contribution under the terms of the license.
AUTHOR
David Golden <dagolden@cpan.org>
COPYRIGHT AND LICENSE
This software is Copyright (c) 2012 by David Golden.
This is free software, licensed under:
The Apache License, Version 2.0, January 2004