What's fishy (to me) is that you have an init in the base class that creates, while all of the child classes have an init that initializes.That's not strictly true, the object is created by Class::DBI itself (usually after a ->retrieve()), all that the init does is rebless the object to a more "specific" class, if you will. Simply renaming the method is certainly the easiest way to do it (and probably I'll end up doing that); however, hypothetically speaking, there is no reason (apart from sanity) why the init on the more specific class wouldn't do the same thing - rebless to a yet more specific class and init that. It's easy to imagine a more general hiearchy of related classes being stored in the same table, each having to descend through some number of these init's until it gets to it's final class. Of course a better way of doing that would probably be a factory that immediately reblesses to the final class that the record ends up with, whose init travels up the inheritance tree with SUPER. (though it is possible to imagine that you need the intermediate classes to decided what class the next step should be) Not that I would ever want to do such a thing, but I was still curious. | [reply] |
Sanity is an excellent reason not to do such things - it's best not to even speak of them, lest we wake the Elder Gods from their slumber and unleash chaos upon the world...
| [reply] |
Another thing - you've also booby-trapped all of the child classes by letting them inherit a function they cannot safely use. If anyone else will be using these classes, maybe you should make the "create" function private. I forget if you have to do tricks to achieve "private" functionality in Perl - it's been over a year since I wrote a Perl module... | [reply] |