[Chicago-talk] super complex object

Steven Lembark lembark at wrkhors.com
Thu Aug 4 06:25:41 PDT 2005


> I know I can take the functional groupings of the "meta" functions and
> create classes  out of them and then do multiple inheritance to get their
> methods into the base object,  but there are three problems with that.
> The first is that it increases the size object  tree, which slows down
> the application. The second is that no matter what I do, those  objects
> cannot ever function independently, because they need to know too much
> about the  data they manipulate. And third, some of the meta functions,
> like versioning, influences  everything else, and therefore cannot truely
> be completely factored out of everything  else.

This is perl, not java: Classes Define Behavior.

You do not need the class-from-hell just to have
data sharing. The object contains data, but that
does not mean your class structure has to be all
in one place.

There isn't any real performance hit from
inheritence in Perl iff you don't manipulate the
symbol table for the classes heavily. The
dispatcher uses a hash lookup to resolve method
calls that skips inheritence levels after the
first lookup.

Net resuilt is that you can decompose the whole
thing into base classes without any real
performance hit and at least give yourself some
breathing room maintaining the internals.

If a lot of classes need to add data into a
central object look up NEXT::init, that is
exactly what it's designed for. The derived
class's constructor passes its new object
through the inherited initializers to get a
composite data structure (hash or array,
I'm about to add hash-of-arrays). This can
also be used to assemble fairly complicated
data structures or dispatch tables.

One approach to this situation is Tim Bunce's
trick in DBI: use a local hash for metadata.
In that case you have a lexical meta hash for
the object within each class for its private
stuff (destructor does a delete $meta{$obj})
and the shared portion lives in the object
itself. That at least encapsulates what you
consider public from any private data. This
also protects the users if they want to store
any of their own data in the object since they
are less likely to overwrite something useful.


-- 
Steven Lembark                                       85-09 90th Street
Workhorse Computing                                Woodhaven, NY 11421
lembark at wrkhors.com                                     1 888 359 3508


More information about the Chicago-talk mailing list