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,
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
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 { /*
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
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()?
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
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.
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
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
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
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
11 matches
Mail list logo