Re: override built-in mail()
| From: | Thijs Lensselink | Date: | Fri, 04 Feb 2011 22:10:36 +0000 |
| Subject: | Re: override built-in mail() | ||
| References: | 1 2 3 4 5 6 7 8 9 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-311154@lists.php.net to get a copy of this message | ||
On 02/04/2011 09:49 PM, David Harkness wrote:
> On Fri, Feb 4, 2011 at 12:42 PM, Hansen, Mike <Mike.Hansen@atmel.com> wrote:
>
>> I would opt for using my_mail and not overriding a built-in function. It
>> seems to me that it would just cause confusion for the next developer who
>> takes care of your code. You know, that psychopathic programmer that knows
>> your address. =)
>>
>
> Yes, better to create your own function (or class) to abstract the mail()
> API of your choosing is the better route. You'll have to retrofit the script
> to use it, but you can then swap in different mail systems later without
> changing the client. Even when you don't anticipate needing to switch to a
> different provider, adding an abstraction layer from the start is often
> cheap enough to warrant the risk of never needing to change the
> implementation underneath.
>
> David
>
I should have added.
Running APD or runkit in production is probably not a good idea. And
renaming a core function just the same. Monkey patching is a nice
solution. But can cause confusion as well.
Like Mike and David say. Better role your own function / class for this.