make PDF::Table more OOP-ish

[kamenov]

[PhilterPaper]

It could be difficult to maintain compatibility with existing user code if there are major changes to the architecture. Adding OOP versions of procedural calls would bloat the code, although procedural versions might be deprecated and eventually removed. Any examples?

[PhilterPaper]

Comment from Desislav:

As far as remember what i wanted to achieve - the internal structure of the module is in very procedural style - many parameters and flags, long methods, data structures in hashes etc. etc. so i wanted to extract a bit of the internals into small objects and encapsulate state and behaviour to make the whole model easier to manage and debug.

We'll have to see if this refactoring is worthwhile. Anything exposed to the outside world could be incompatible with existing code, and thus a big problem.

Add: This would require parallel libraries: the existing procedural code, and an added class for OO code. This is like what MySQL gives you in a website: a choice of procedural and OO. Of course, the duplication bloats the code to some degree, so I still don't know if it's worth it.

Add: We could explore making the OO library a wrapper around the existing procedural code, reducing duplication and bloat. Of course, this doesn't really help all that much if the objective is to simplify and clean up the internals of PDF::Table, and not just present a pretty OO interface to end-users.