Issues

ZF-10367: public Zend_Mail::clearHeader() method?

Description

Many of the things you set with public add() methods on a Zend_Mail object, you can remove again using corresponding clear() methods, but this isn't the case with headers.

There is the protected Zend_Mail::_clearHeader() method, but (unless I'm missing something) there isn't a clear reason why this isn't safe to have a public method for. One shouldn't have to extend Zend_Mail just to clear a header, when there's already methods like clearRecipients(), clearSubject() etc.

The usage scenario where this would be handy is when you're looping through recipients within the same Zend_Mail instance, changing some things (e.g. clearRecipients()->addTo('foo@bar.com') ), then calling send() again. You might've also added some custom header with addHeader() which you then want to remove and add differently for the next recipient. Presently this is only possible by extending Zend_Mail, or creating a new Zend_Mail instance for each recipient (which may get problematic if you have things like attachments in the mix).

A public clearHeader() method could be as simple as:


        public function clearHeader($headerName)
        {   
            $this->_clearHeader($headerName);
            
            return $this;
        }

Comments

Patch with test attached. Maintains protected _clearHeader() method as a proxy for backwards compatibility for classes that have extended Zend_Mail.

Would be interesting to know why _clearRecipients() was made a protected method to begin with? Any ideas?

I don't know why the original author, of one of its successors did it like this. I suppose because he doesn't want the enduser to call it (doh ;D). Zend_Mail suffers from a lot of this kind of decisions and a bad API-design alltogether. That is why I plan to do a rewrite of its core for ZF2, so we have something that actually works.

Patch applied to trunk and 1.11 release branch -- thanks!

Interestingly, on the subject of backwards-compatibility, this provides an example of how having to work around weaknesses in the API can actually cause a kind of backwards-incompatibility where framework users have extended classes to provide those work-arounds.

For example, my work-around for the lack of a public clearHeader() method in Zend_Mail was to create a method in an extended class which did the reverse of what this patch now does (see my original description above). So if I upgrade now from ZF 1.10 to 1.11, I actually have to remove my extended public method to avoid an infinite-loop method calling scenario.

Funny..