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.
Zeev
At 06:30 PM 6/30/2002, Sascha Schumann wrote:
> > How is it better than add_header_ex()?
>
> 1. The function name misrepresents the function's task.
> It sets the response code, replaces or adds a header.
> Simply calling it 'operation' is therefore a clearer
> choice.
>
> 2. The new function has a more generic interface which I
> prefer over sapi_add_header_ex, sapi_add_header7 and so
> on. This interface can be extended without adding new
> APIs. In the case of SAPI_HEADER_ADD/REPLACE, source code
> level compatibility is guaranteed by initializing the
> parameter as
>
> sapi_header_line ctr = {0};
>
> so that additional fields are properly initialized as zero.
>
> 3. It also addresses a design issue of the sapi_add_header
> interface. The new function never deallocates memory
> which was allocated by the caller. The impact of
> duplicating 1-2 strings per request does not outweigh
> violating a basic design principle IMHO.
>
> - Sascha
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
