In both cases, you can just use the scalar holding the method name directly:
$obj->$method(@arguments);
and
$class->$method(@arguments);
| [reply]
[d/l]
[select] |
Thanks, exactly what I needed! Sometimes Perl can be really simple...
| [reply] |
Maybe it's too early and I haven't had my third cup of coffee, but the concept of using the content of a variable to determine OO method/class calls sounds a bit scary. I can see a real debugging nightmare down the road.
Does your design really depend on letting your User input the name of the function that needs to be performed? Or, it the name computed from input provided by the User? How are you planning to handle the typo problem? (And please tell me you aren't going to use autoload() to resolve the unknown name.)
Before I went down the path of using variables as names, I would take a few minutes and review the 'logic' that is requiring these measures. If you can't get out of the box, then stick in a block of comments explaining why things are as they are; make sure that the code that vets out the content of your variable is bullet-proof; and stick the call inside an eval() block. And don't be surprised when the block fails every so often on 'function unknown'.
I'd still go back to the designer and look at them over the tops of my glasses....
Update (after another cuppa)
The more I consider your question, the more it sounds you are writing a wrapper for a library that uses function-signatures in the dispatch process (C++ and it's propensity to mangle names comes forcibly to mind). If this is the case, please revisit the design decision that mandates the wrapper in Perl. You might be better served (and your Maintenance Programmers will be less likely to use your name as a swear-word) agreeing to use a common language, even it it means rewriting the Library in Perl.
As an aside, I am horribly curious to know about the application that brought about the original question. It sounds like Fun, in a perverse sense of the word.
----
I Go Back to Sleep, Now.
OGB
| [reply] |
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).
| [reply] |