Objects can adopt other objects which creates a tracked relationship within the class itself. Those child objects can, in turn, adopt objects of their own. The result is a hierarchal tree of objects, with the parent being the trunk.

Perl uses a reference-counting garbage collection system which destroys objects and data structures as the last reference to it goes out of scope. This results in an object being destroyed before any internal data structures or objects referenced internally. In most cases this works just fine since many programs really don't care how things are destroyed, just as long as they are.

Occasionally, though, we do care. Take, for instance, a database-backed application that delays commits to the database until after all changes are made. Updates made to a collection of records can be flushed as as the parent object goes out of scope. In a regular object framework the parent object would be released, which could be a problem if it owned the database connection object. In this framework, though, the children are pre-emptively released first, triggering their DESTROY methods beforehand, in which the database commit is made:

Objects based on this class will be opaque objects instead of the traditional blessed hash references in which the hash elements could be access directly through dereferencing. This prevents access to internal data structures outside of the published interface. This does mean, though, that you can't access your data directly, either. You must use a provided method to retrieve that data from the class storage.

A benefit of having an opaque object is that allows for scoping of both properties and methods. This provides for the following access restrictions:

private accessible only to members of this object's class
restricted accessible to members of this object's class
and subclasses
public globally accessible

Attempts to access either from outside the approved scope will cause the code to croak. There is an exception, however: private properties. This aren't just protected, they're hidden. This allows various subclasses to use the same names for internal properties without fear of name space violations.

Properties can be explicitly declared to be of certain primitive data types. This allows some built in validation of values being set. Known scalar value types are scalar, code, glob, and reference.

Properties can also house hashes and arrays. When this is leveraged it allows for properties contents to be managed in ways similar to their raw counterparts. You can retrieve individual elements, add, set, test for, and so on.

In a hierarchal system of object ownership the parent objects have strong references to their children. This frees you from having to code and track object references yourself. Sometimes, however, it's not always convenient or intuitive to remember which parent owns what objects when you have a multilevel hierarchy. Because of that this class implements an alias system to make retrieval simpler.

Aliases are unique within each hierarchy or tree. Consider the following hierarchy in which every node is an object member:

Subroutines and constants are provided strictly for use by derived classes within their defined methods. To avoid any confusion all of our exportable symbols are *not* exported by default. You have to specifically import the all tag set. Because these subroutines should not be used outside of the class they are all preceded by an underscore, like any other private function.

Methods, on the other hand, are meant for direct and global use. With the exception of new and DESTROY they should all be safe to override.

The following subroutines, methods, and/or constants are are orgnanized according to their functional domain (as outlined above).

You'll note that both @_properties and @_methods are arrays of arrays, which each subarray containing the elements for each property or method. The first element is always the attributes and the second the name of the property or method. In the case of the former a third argument is also allowed: a default value for the property:

This method must not be overridden in any subclass, but be used as-is. That said, subclasses still have complete control over whether this method call succeeds via the _initialize method, which all subclasses must provide themselves.

When the object contsructor is called an object is instantiated, then _initialize is called with all of the new arguments passed on unaltered. The _initialize method is responsible for an internal initialization necessary as well as any validation. It must return a boolean value which determines whether a valid object reference is returned by the new method, or undef.

NOTE: all superclasses based on Class::EHierarchy containing a _initialize method will also be called, all prior to the current subclass' method.

Once the basic object has been constructed it calls the _initialize method, giving it a complete set of the arguments the constructor was called with. The form of those arguments, whether as an associative array or simple array, is up to the coder.

You can do whatever you want in this method, including creating and adopting child objects. You can also dynamically generate properties and methods using the _declProp and _declMethod class functions. Both are documented below.

This method must return a boolean value. A false return value will cause the constructor to tear everything back down and return undef to the caller.

This function is used to create named properties while declaring they access scope and type.

Constants describing property attributes are OR'ed together, and only one scope and one type from each list should be used at a time. Using multiple types or scopes to describe any particular property will make it essentially inaccessible.

Type, if omitted, defaults to CEH_SCALAR, Scope defaults to CEH_PUB.

NOTE:CEH_NO_UNDEF only applies to psuedo-scalar types like proper scalars, references, etc. This has no effect on array members or hash values.

This function is is used to create wrappers for those functions whose access you want to restrict. It works along the same lines as properties and uses the same scoping constants for the attribute.

Only methods defined within the subclass can have scoping declared. You cannot call this method for inherited methods.

NOTE: Since scoping is applied to the class symbol table (not on a per object basis) any given method can only be scoped once. That means you can't do crazy things like make public methods private, or vice-versa.

A DESTROY method is provided by this class and must not be overridden by any subclass. It is this method that provides the ordered termination property of hierarchal objects. Any code you wish to be executed during this phase can be put into a _deconstruct method in your subclass. If it's available it will be executed after any children have been released.

In order for objects to be destroyed from the bottom up it is important to track the hierarchal relationship between them. This class uses a familial parent/child paradigm for doing so.

In short, objects can adopt and disown other objects. Adopted objects become children of the parent object. Any object being destroyed preemptively triggers deconstruction routines on all of its children before cleaning up itself. This ensures that any child needing parental resources for final commits, etc., has those available.

Additional methods are also present to make it easier for objects to interact with their immediate family of objects. Those are documented in this section. More powerful methods also exist as part of the alias system and are documented in their own section.

This method attempts to adopt the passed objects as children. It returns a boolean value which is true only if all objects were successfully adopted. Only subclasses for Class::EHierarchy can be adopted. Any object that isn't based on this class will cause this method to return a false value.

This method attempts to disown all the passed objects as children. It returns a boolean value based on its success in doing so. Asking it to disown an object it had never adopted in the first place will be silently ignored and still return true.

Disowning objects is a prerequisite for Perl's garbage collection to work and release those objects completely from memory. The DESTROY method provided by this class automatically does this for parent objects going out of scope. You may still need to do this explicitly if your parent object manages objects which may need to be released well prior to any garbage collection on the parent.

Opaque objects can't access their own data directly, and so must use methods to access them. There is one principle method for doing so, but note that in a later section a whole suite of convenience functions also exist to make hash and array property access easier.

This method provides a generic property accessor that abides by the scoping attributes given by _declProp. This means that basic reference types are checked for during assignment, as well as flags like CEH_NO_UNDEF.

A boolean value is returned on attempts to set values.

Any attempt to access a nonexistent property will cause the code to croak.

NOTE: Given that the presence of additional arguments after the property name sets this method into 'write' mode, there is obviously no way to use this to empty a hash or array property. For that please see the purge method below.

Properties are validated automatically on set attempts for the various scalar types (code, glob, reference, scalar value), as well as arrays and hashes. Working through a single accessor method for individual array or hash elements, however, can be very inconvenient. For that reason many common array/hash functions have been implemented as methods.

This method pushes additional elements onto the specified array property. Calling this method on any non-array property will cause the program to croak. It returns the return value from the push function.

This method unshifts additional elements onto the specified array property. Calling this method on any non-array property will cause the program to croak. It returns the return value from the unshift operation.

This method checks for the existance of the specified key in the hash property. Calling this method on any non-hash property will cause the program to croack. It returns the return value from the exists function.

This method is a unified method for retrieving specific element(s) from both hashes and arrays. Hash values are retrieved in the order of the specified keys, while array elements are retrieved in the order of the specified ordinal indexes.

This method is a unified method for removing specific elements from both hashes and arrays. A list of keys is needed for hash elements, a list of ordinal indexes is needed for arrays.

NOTE: In the case of arrays please note that an element removed in the middle of an array does cause the following elements to be shifted accordingly. This method is really only useful for removing a few elements at a time from an array. Using it for large swaths of elements will likely prove it to be poorly performing. You're better of retrieving the entire array yourself via the property method, splicing what you need, and calling property again to set the new array contents.

This method gets/sets the alias for the object. Gets always return a string, while sets return a boolean value. This can be false if the proposed alias is already in use by another object in its hierarchy.

As noted in the CREDIT section below portions of the concept and implementation of opaque objects were taken from Damian Conway's module Class::Std(3). I have chosen to deviate from his implementation in a few key areas, and any or all of them might be considered bugs and/or limitations.

Damian relies on an ident function in his module to provide each module with a unique identifier. Unfortunately, when retrieving internal data structures he wants you to use them for each and every retrieval. While effective, this exercises the stack a bit more and provides a performance penalty.

To avoid that penalty I chose to store the ID in the anonymous scalar we referenced as part of object instantiation. While in theory this could be overwritten and wreak havoc in the class data structures I think the performance benefits outweigh it. I am hedging that most of us won't accidentally dereference our object reference and overwrite it.

Another benefit of storing the ID directly is that the code you'll write based on this class looks a lot more like traditional Perl OO. If you're a devout Damian disciple that's probably not a benefit, but his '$attr_foo{ident $self}' notation really rubs me the wrong way.

Another performance concern I had with Class::Std was the heavy reliance on internal hashes. This penalizes you on both memory and performance utilization. So, I changed my internal _ident function to be based purely on an ordinal index value, which allowed me to use arrays to store all of the applicable class data.

End sum, this module gives you the hierarchal qualities I needed along with some of the opaque object benefits of Class::Std(3), but in a manner that possibly interferes less with one's natural style of coding while being generally more efficient and system friendly.

The notion and portions of the implementation of opaque objects were lifted from Damian Conway's Class::Std(3) module. Conway has a multitude of great ideas, and I'm grateful that he shares so much with the community.