. . . not a solution to the general problem of possible changes to the underlying data representation. Although it may be a perfectly acceptable solution in the simple case you describe.

I think that Perl could switch quite easily from "return an int" to "return a complext object" either by overloading numification on the overloaded object, or by returning a tied scalar. This may not be always possible, either, but I bet it will work in many cases.

Does that sound so awful?

Your first paragraph describes what I'm doing already pretty well. Right now, if I need to add new report, I add the class name to a certain hash in the base ReportGenerator class (which can be used to give the user a list of possible reports to generate) and then code the report subclass to extract stuff from the data class.

In your model, I would also need to add a subroutine to the data class to generate the report. Which I suppose isn't the worst thing that could be done, but I don't see why I need to do it when I don't see any particular problems with my current model. Even if I were to start this project from scratch, I would still probably do the report generator the same way.

Incidently, I read over the author's article Why getter and setter methods are evil. It appears he doesn't think all get and set methods are evil--just the ones that are expected to return a primitive type. Returning more complex objects is fine by him.