Re: sapi_header_op
| From: | Sascha Schumann | Date: | Sun, 30 Jun 2002 15:54:06 +0000 |
| Subject: | Re: sapi_header_op | ||
| References: | 1 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-85680@lists.php.net to get a copy of this message | ||
On Sun, 30 Jun 2002, Zeev Suraski wrote:
> Thanks for the clarifications. IMHO the advantage does not outweigh the
> disadvantages (slower, more cumbersome to use, will require everyone to
> implement two interfaces), so personally, I'm -1.
Where is your reasoning for a veto? I don't see any.
First, the original function itself is slow. The added
parameter handling does not make it measurably slower. It is
not a fast path function anyway, so speed is not a concern.
Second, sapi_add_header_ex confuses the hell out of
programmers, because of its bad interface design. It is
the *only* function in PHP which has to state up-front:
"This function expects a *duplicated* string, that was
previously emalloc()'d . Pointers sent to this functions
will be automatically freed by the framework.
sapi_header_op completely eliminates this.
Third, it does not force anyone to implement two interfaces
(I wonder where you got that idea).
- Sascha