. . . 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.
----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer
: () { :|:& };:
Note: All code is untested, unless otherwise stated
In reply to Re^7: (OT) OOUI: multiple views in an object.
by hardburn
in thread (OT) OOUI: multiple views in an object.
by BUU
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |