You spoke of Perl programming tricks and techniques and of patterns and strategies (as I hoped you would).
Let me try to summarize the lessons learned.
On Perl programming:
True enough. I could store it in a package variable
my $thisClass = "MyModule";In addition, I could encapsulate this variable by placing it together with the module code inside a block.
Good point. I expected that there would be a way to check the class name better than my clumsy
if ref $_[0] && ref $_[0] eq $_[0]->{class};
and I have seen UNIVERSAL::isa mentioned in print before. Now I could write if $_[0]->isa($thisClass);
Looks interesting, but maybe more than what I need right now.
Sure, I knew this, from reading the Camel Book. But now I see how it can apply to my case.
... The constructor for the object API is defined in the old module so the actual class name of your new object API is hidden from the user.
Indeed, my unstated objective was not to have new names for subs promoted methods or for the new OO module.
Your suggestion seems to meet this goal nicely.
It also dovetails with sauoq's and adrianh's.
BTW, you look like a Monastery novice who is not a Perl novice.
On strategies for morphing:
Fundamentally right. It seemed a bit heavy, until blssu showed how to do it in one compact module.
I agree 100% (maybe more). The old module does not have a test suite, but it will have one soon.
In reply to Re: How to morph a plain module to OO
by Rudif
in thread How to morph a plain module to OO
by Rudif
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |