Thank you for your insight. Yes, the design at it's current stage is convoluted and I'm trying to solve a migration problem here.

What I have is an existing application that extensively uses DBIx::Class. I have an object class that is subclassed, a single SQL table is used to store the class data and the additional data of the various subclasses. This is a huge waste of space. Furthermore, the object hierarchy was incorrectly designed and I'm find myself having the need to subclass the objects into a different hierarchy. Later I will pull out the existing subclass hierarchy and give the original class an attribute referencing that. Sounds convoluted, and it is, but there is too much code to break, so I have to do it in steps.

I can't waste all the space for unused subclass fields, so I created different tables for the various additional subclass data. This is all fine and would work by polymorphy except the object already has that different inheritance hierarchy attached. I can't very well bless the objects into two packages. In order to get the additional data into the instances I need to have a relation to the additional data table and also call some functions there for storing and retrieving the data. I could just make a base class for the additonal data and subclass that, except that DBIx::Class doesn't seem to support subclass data in different tables - I have to do this myself and dispatch to the correct methods by hand

Unfortunately one of them is a class method, not an instance method (I need to call it without having an instance; it handles data verification that needs to be done _before_ an instance is created). So I need the package name to call the class method - and the package name is variable in this case. Beware that there is no real subclassing going on here - this won't work with DBIx::Class if the subclass data is not all in the same table.

As for calling variable method names; this is no longer needed in this application, but it was an equally absurd situation.

Yes, you are right, the design is horrible. It will get better when the multiple inheritance is no longer needed, though. DBIx::Class only seems to support two methods for subclassing, though: either store all subclass data in the superclass table as additional attributes (huge waste of space in this case), or store subclass data as a data structure in a blob in the superclass table (ungodly breakage of relational structure).