Re: Working with Standard Modules...

In general it is best to sub-class an existing module. Although it may not be easy or straightforward it is generally possible.

For example the Mail::Box module gathers together several existing mail modules under a single OO interface. This entailed some of the problems that you are facing.

The author, Mark Overmeer, gave an excellent talk about it at YAPC::Eu 2001. The slides are here.

In particular he demonstrated a very clever idea for using AUTOLOAD to re-bless an object into a class that supported a called method. (This isn't directly applicable to your case but it is interesting nevertheless)

John.
--

Comment on Re: Working with Standard Modules...

Replies are listed 'Best First'.
Re: Re: Working with Standard Modules... by demerphq (Chancellor) on Sep 26, 2001 at 18:06 UTC
In general it is best to sub-class an existing module. Although it may not be easy or straightforward it is generally possible. Unfortunately in this case it doesn't seem to be very feasable. The problem is that almost all of the calls within the module are hard wired to each other. Even though there is a Benchmark object (blessed using the single argument form!) none of the routines take $self references so they can't be called as methods, and should I call one as a procedure then it will call all of its friends as procedures, completely ignoring what overriden methods I have provided. So the question for me was total ground up rewrite in my own module or to convert the entire thing into an OO version? I chose the later and have now completed the majority of work converting it into an OO structure. This basically meant trawling the code for subroutines and subroutine calls and adding in a $self pointer, splitting out functionality into different objects etc. Now I could reimplement the original package just through calls to mine, but no way I could go the other way. Once Im done I plan to post it here for revue and comments. Although as the module has no copyright information I think I might need permission. Yves -- You are not ready to use symrefs unless you already know why they are bad. -- tadmc (CLPM)	[reply]

Replies are listed 'Best First'.

Re: Re: Working with Standard Modules...
by demerphq (Chancellor) on Sep 26, 2001 at 18:06 UTC

In general it is best to sub-class an existing module. Although it may not be easy or straightforward it is generally possible.

Unfortunately in this case it doesn't seem to be very feasable. The problem is that almost all of the calls within the module are hard wired to each other. Even though there is a Benchmark object (blessed using the single argument form!) none of the routines take $self references so they can't be called as methods, and should I call one as a procedure then it will call all of its friends as procedures, completely ignoring what overriden methods I have provided.

So the question for me was total ground up rewrite in my own module or to convert the entire thing into an OO version?

I chose the later and have now completed the majority of work converting it into an OO structure. This basically meant trawling the code for subroutines and subroutine calls and adding in a $self pointer, splitting out functionality into different objects etc. Now I could reimplement the original package just through calls to mine, but no way I could go the other way.

Once Im done I plan to post it here for revue and comments.

Although as the module has no copyright information I think I might need permission.

Yves
--
You are not ready to use symrefs unless you already know why they are bad. -- tadmc (CLPM)

[reply]