My first real understanding of Object Oriented Perl was reading “Perl Testing: A Developer’s Notebook” which shows some simple basics, but doesn’t really cover things that can get tricky like nested and multiple inheritance. Recently, I’ve been looking a little closer, rereading perlobj, perltoot,perltooc, perlboot, and Learning Perl (chapter 11.)

I’ve been looking at a way to build a good base class that handles instantiation and initialization (new), but haven’t found a good way to inherit new in a functional way. Standard practice seems to be to have a base sub new() call $self->init() and then have sub init() call $self->SUPER::init() on down the stack.

My concern then is worrying about what order things happen in the @ISA list. You have to be very careful, and when you inherit from other frameworks, you can’t be too sure of what happens until it does. I don’t have a good example, just a general feeling of unease.

But I’ve been looking on CPAN at several frameworks. What I’d like is a mixin style of inheritance so that I can have a domain object that, based on context can:

1. define domain objects as a simple hash
2. persist to a database
3. handle REST requests and return XML/JSON/HTML based on “Accept” type
4. Generate XML in a safe way
5. restrict access and actions based on user permissions

So I want a class system that doesn’t try to hide stuff in a stash. I want to treat it as a hash when it is a hash. I want the hash to map directly to XML, and methods to operate on that hash. Request processing and access control can probably be externalized.

The two main parts, DB persistence, and XML generation I’d love to inherit from base classes, but it doesn’t look like there’s anything that does a decent job.

XML::Generator seems like the only level of abstraction between XML::Simple and XML::DOM. Simple only has XMLOut which is really just “print” and DOM is well, DOM. XML::Generator has a simple array mechanism that will probably be enough for what I need, but doesn’t feel that safe. I’m not sure if ordering of similar elements is guaranteed. There was one other similar package that didn’t seem to have even that, but I don’t remember what it was. I can’t believe there’s nothing like Java’s XMLBeans or PHP’s SimpleXML.

OO persistence is really scary. The top three contenders seem to be Class::DBI, DBIx::Class, and Rose::DB. It sounds like Rose::DB is the best performance wise (by a lot — though performance shouldn’t be an issue at all.) I hear a lot of people saying essentially CDBI is out-dated, but it has, in my opinion, a much better API than DBIC. Apparently there are gotchas with CDBI, but the always cited ability to do joins is not one of them. But I don’t want a package that defines it’s own query language. I want to map objects to the database, not create objects out of database tables. Objects contain data, they don’t describe it.

OO Frameworks are also a non-starter. Classes and Moose seem to be top preferences here, but I looked at Moose and it doesn’t make sense, and seems to be a huge waste of resources. I’m not sure what it buys me other than *yet another* “special” jargon. Classes pragma doesn’t seem to buy me anything, since it looks like I have to write the same boilerplate for contructors and accessors. The documentation seems to be saying I won’t have to write tests for my constructors and accessors, because I can trust they did a good job. But if I just come up with a base class and a simple convention, I only have to write those tests once, myself. While it is a sad truth that in dynamic languages (and perl is perhaps more dynamic than just about anything but lisp) type typos don’t get caught until runtime, it’s usually a pretty obvious failure. I don’t need to check my package name to figure out why my $foo can’t unstrap() it’s {bar}