Re: [PHP-DEV] sapi_header_op

2002-07-01 Thread Andi Gutmans
At 07:03 AM 7/1/2002 +0200, Sascha Schumann wrote: I understood the rational of using a struct from the beginning. I still in general don't like using structs very much because as I mentioned it's not as easy to use. I prefer having 2-3 methods then having one method which I Well,

Re: [PHP-DEV] sapi_header_op

2002-06-30 Thread Rasmus Lerdorf
Yes, probably a good idea. On Sun, 30 Jun 2002, Sascha Schumann wrote: I think it is time for deprecating sapi_add_header* in favor of a more general function, called sapi_header_op. Let me quickly recapitulate the history. The original function sapi_add_header added and

Re: [PHP-DEV] sapi_header_op

2002-06-30 Thread Zeev Suraski
At 02:44 PM 6/30/2002, Sascha Schumann wrote: typedef struct { char *line; /* If you allocated this, you need to free it yourself */ uint line_len; long response_code; /* long due to zend_parse_parameters compatibility */ } sapi_header_line; typedef enum { /*

Re: [PHP-DEV] sapi_header_op

2002-06-30 Thread Sascha Schumann
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

Re: [PHP-DEV] sapi_header_op

2002-06-30 Thread Zeev Suraski
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()?

Re: [PHP-DEV] sapi_header_op

2002-06-30 Thread Sascha Schumann
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

Re: [PHP-DEV] sapi_header_op

2002-06-30 Thread Zeev Suraski
At 06:54 PM 6/30/2002, Sascha Schumann wrote: 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.

Re: [PHP-DEV] sapi_header_op

2002-06-30 Thread Andi Gutmans
My only problem with this patch is that I don't like API's which pass around structs. I always find it cumbersome to have to create and fill the struct and then pass it. Can you think of something similar without using structs? Andi At 01:44 PM 6/30/2002 +0200, Sascha Schumann wrote: I

Re: [PHP-DEV] sapi_header_op

2002-06-30 Thread Sascha Schumann
On Sun, 30 Jun 2002, Andi Gutmans wrote: My only problem with this patch is that I don't like API's which pass around structs. I always find it cumbersome to have to create and fill the struct and then pass it. Can you think of something similar without using structs? If you look at the

Re: [PHP-DEV] sapi_header_op

2002-06-30 Thread Andi Gutmans
At 10:03 PM 6/30/2002 +0200, Sascha Schumann wrote: On Sun, 30 Jun 2002, Andi Gutmans wrote: My only problem with this patch is that I don't like API's which pass around structs. I always find it cumbersome to have to create and fill the struct and then pass it. Can you think of

Re: [PHP-DEV] sapi_header_op

2002-06-30 Thread Sascha Schumann
I understood the rational of using a struct from the beginning. I still in general don't like using structs very much because as I mentioned it's not as easy to use. I prefer having 2-3 methods then having one method which I Well, feel free to post those 2-3 methods which cover all