Re: Should I extract Mail::Sender's debuging into a separate module?

Moving all of the debugging code into its own module makes plenty of sense. The code will only be compiled if needed, it would be easier to extend and there would be less clutter in the main body of code.

As for what to name it, that really depends upon what you want it to do. Mail::Sender::Logging is a good name, but if you're going to extend the functionality, it might not be appropriate. If all you're going to do is log, though, you might want to check out Tie::FileHandle::Buffer. (It doesn't have proper test coverage though). If it works as advertised, it could greatly simplify your problem.

As for the other methods to support: perhaps you could just make the module subclassable and allow other people to add their own methods as needed? That will take more work and more documentation, but it will make it more flexible.

Cheers,
Ovid

New address of my CGI Course.
Silence is Evil (feel free to copy and distribute widely - note copyright text)

Comment on Re: Should I extract Mail::Sender's debuging into a separate module?

Replies are listed 'Best First'.
Re: Re: Should I extract Mail::Sender's debuging into a separate module? by Jenda (Abbot) on May 27, 2003 at 14:53 UTC
Well the code is compiled only if needed. It's in a here-doc string that gets eval()ed if necessary. I could name it Mail::Sender::Logging or even just Mail::Sender::DBIO if I planed to use it only from Mail::Sender, but then I might just leave it inside Sender.pm. The real question is ... would someone else find this helpfull? I mean with a little trickery you might even be able to sneak such debuging to a module that has no debugging yet. You'd just have to extract the socket it contains somewhere inside and replace it with a handle tied to this class that would forward all reads/writes to the real socket: `use Some::Module; use Socket::Logger; #or whatever name it ends up with my $obj = Some::Module->new(parameters); $obj->{_socket} = Socket::Logger->new($obj->{_socket}, $logfilepath); ... use the $obj` [download] It's a good idea about the subclassability, thanks for that. Jenda Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Rick Osborne Edit by castaway: Closed small tag in signature	[reply] [d/l]

Replies are listed 'Best First'.

Re: Re: Should I extract Mail::Sender's debuging into a separate module?
by Jenda (Abbot) on May 27, 2003 at 14:53 UTC

Well the code is compiled only if needed. It's in a here-doc string that gets eval()ed if necessary.

I could name it Mail::Sender::Logging or even just Mail::Sender::DBIO if I planed to use it only from Mail::Sender, but then I might just leave it inside Sender.pm. The real question is ... would someone else find this helpfull? I mean with a little trickery you might even be able to sneak such debuging to a module that has no debugging yet. You'd just have to extract the socket it contains somewhere inside and replace it with a handle tied to this class that would forward all reads/writes to the real socket:

use Some::Module;
use Socket::Logger; #or whatever name it ends up with

my $obj = Some::Module->new(parameters);

$obj->{_socket} = Socket::Logger->new($obj->{_socket}, $logfilepath);

... use the $obj
[download]

It's a good idea about the subclassability, thanks for that.

Jenda
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
-- Rick Osborne

Edit by castaway: Closed small tag in signature

[reply]
[d/l]