Re: Package proposal: Mail_RFC822_Headers

> > I've made a class Mail_RFC822_Headers, which, though it quite small (at > > least for the time being) implements the common features form the mentioned > > packages. > > Why do we need a fourth class if we already have three performing > essentially the same task? The idea was actually to move the code from the tree existing classes into one 'common' class. > If I were you I'd instead try to improve the existing solutions I personally believe, that merging the code from the existing solutions (and fixing some package specific problems), is a improvement. Any package that used the common class would benefit from the joined improvements of the commonly used package - and if a forth package were to parse message headers, it need only to include the common class... > and perhaps make two of them use the existing capabilites of the third "base class". That was also my first thought, but why should one have to waste flops on parsing totally unnecessary code? Net_IMAP::getParsedHeaders() fetches a message, so that function is disqualified... Mail_MimeDecode::_parseHeaders() could be used by the other two packages (my first thought), but why should one have to include the rest of the mime stuff, if one only works with headers - and furthermore it's a private function, so it's also disqualified... Net_NNTP::parseHeaders($headers) (upcoming version) could also be used, but people using the already large Net_IMAP properly wouldn't like including the unnecessary NNTP stuff. Of course the header parsing stuff could be moved Net_NNTP_Headers or Net_NNTP_HeaderParsing or something like that, but that doesn't make that much sense, does it? Summa summarum is, that the header parsing functions ought to be implemented in a separate file, either under a new package or under for instance Mail_Mime. Heino