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
>
> We
> 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
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
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
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 t
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.
>
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 a
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()?
>
>
> 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
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 { /
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
11 matches
Mail list logo
