develooper Front page | perl.moose | Postings from February 2009

Re: advice on wrapping methods from a superclass

Thread Previous
John Napiorkowski
February 11, 2009 06:52
Re: advice on wrapping methods from a superclass
Message ID:

----- Original Message ----
From: Jonathan Swartz <>
Sent: Wednesday, February 11, 2009 3:55:50 AM
Subject: advice on wrapping methods from a superclass

CHI ( is a Moose-based caching framework. There is a driver superclass (CHI::Driver) and various driver subclasses that implement different cache backends (CHI::Driver::File, CHI::Driver::Memcached, etc.) Drivers implement standard methods like remove() and clear(). e.g Currently, if you call $cache->remove(), it goes directly to the driver subclass.

The problem is that there are now legitimate reasons to "wrap" these methods at the CHI/ superclass level (meaning, do something before and/or after the method). For example, I want to add an optional generic size-awareness feature (the cache can keep track of its own size), which means that we have to adjust size whenever remove() and clear() are called. And I want to log remove() calls the way we currently log get() and set().

So one solution is to define remove() and clear() in CHI/, and have them call _remove() and _clear() in the driver subclasses.  But this kind of change makes me uneasy for several reasons:

* It changes the driver API, i.e. all existing drivers out there have to modified. And we might have to change it again as we identify new methods to wrap.

* The list of 'normal' versus 'underscore' methods becomes rather arbitrary - it's "whatever we've needed to wrap so far".

Moose has before & after modifiers, but can they be defined in the superclass and affect the subclass??

I guess could use a wrapping module, like Sub::Prepend or Hook::LexWrap, on any driver class the first time it is used, e.g. the first time someone says

    CHI->new(driver => 'File')

we wrap the appropriate File methods. But this feels hacky - these tools seem like a way to modify someone else's module, not as a standard part of your own class.

Advice appreciated!


I may not be grasping the exact problem, but I wonder if CHI::Driver shouldn't be a role instead.  Then you could require a method and add a wrapper as well.  Lately I've been thinking unless the class is going to be instantiated it should be a role.  I'm not so down on base classes anymore.  Not sure if that helps. 



Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About