in reply to Re: Overriding Mail::Audit's accept()
in thread Overriding Mail::Audit's accept()

Yikes, I didn't notice that. I was looking around in Mail::Audit's code, but didn't notice the weird constructor. Thanks for pointing this out. Incidentally, has anyone got any idea why Mr. Cozens would choose to make his constructor like this?

Replies are listed 'Best First'.
Re: Re: Re: Overriding Mail::Audit's accept()
by hossman (Prior) on Jun 30, 2003 at 07:05 UTC
    Incidentally, has anyone got any idea why Mr. Cozens would choose to make his constructor like this?

    I only skimmed it, but it looks Mail::Audit::new works more as a factory (for getting either a Mail::Audit::MailInternet or Mail::Audit::MimeEntity object) then as a constructor. It seems like this would have been something that should be mentioned in the perldocs.

    Speaking of the documentation, if your goal is to overide the accept method, then this section of Mail::Audit seems applicable...

    new(%options) ... Other options include the accept, reject or pipe keys, which specify subroutine references to override the methods with those names.
      new(%options)
         ...
         Other options include the accept, reject or pipe keys,
         which specify subroutine references to override the
         methods with those names.

      I saw this in the perldocs, and made a new accept routine via this mechanism, but I could not find a clean way to get at the Mail::Audit object. I couldn't do the equivalent of $item->SUPER::accept... so I would end up having to reimplement accept from scratch, which is not something I am willing to do.

      Also, thanks all for the input. I've decided that if and until I find an acceptible mechanism for overriding accept, I will just stick to my current code, where I manually call another subroutine each time before accept (e.g. summarize($item, $folder); $item->accept($folder)).