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).

In reply to Re^2: Calling instance methods with the method name stored in a variable by Cybris
in thread Calling instance methods with the method name stored in a variable by Cybris

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.