I'd avoid mixing the two models.
If I really needed an imperative interface and an OO interface, I'd be inclined to make an imperative wrapper for an OO library. I'm not 100% sure about how I'd handle the details. I think you'd have to do some autoloading of subroutines.
For example, if I call ImpWrapper::foo(), then ImpWrapper::AUTOLOAD would need to check to see if its global object has a method foo(). If so, we would create ImpWrapper::foo() and have it delegate to $iw_global_obj->foo().
My AUTOLOAD-fu is not really that good, so to be sure of this approach, I'd have to spend more time than I have investigating it. But it seems like it should work pretty well, as long as you don't do anything crazy, like reblessing your wrapper's object into a different class.
I can imagine a general ImpWrap module that allows you to do something like:
package Imperative::TheObject; use ImpWrap TheObject => ( name => foo, address => '123 A Street', foo => 'bar', );
Then ImpWrap would create a TheObject object, and put it into the Imperative::TheObject namespace. ImpWrap would also insert an appropriate AUTOLOAD routine.
If I ever thought I might need such a thing, it might be an interesting project.
TGI says moo
In reply to Re: Is it ok to mix functional and oo programming in one package?
by TGI
in thread Is it ok to mix functional and oo programming in one package?
by leocharre
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |