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 . You will be 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. git clone https://github.com/dagolden/Hash-Objectify.git AUTHOR David Golden 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