deprecated attribute? / naming

[Max Kellermann <ma...@duempel.org>]

On 2005/02/06 21:56, Joe Schaefer <jo...@sunstarsys.com> wrote:
> Given the amount of changes, I think that's a very good idea.  So
> anything we mark in 2.05-dev as deprecated will mean that we're
> planning to remove these items in the 2.06 (non-developer) release,
> ok?

+1

A little bit about names..

I noticed you deprecated "apreq_cookie()" and replaced it by
"apreq_jar_get()". "jar" used to be the name for the class which
collects cookies. I would rather drop the name "jar" now in favor of
"cookie":

 apr_status_t (*cookies)(apreq_env_handle_t *, const apr_table_t **);
 apreq_cookie_t *(*cookie_get)(apreq_env_handle_t *, const char *);

When we're discussing the function names in apreq_env.h, what do you
think about the following renames:

 apreq_args_get -> apreq_get_arg
 apreq_jar_get -> apreq_get_cookie

I'm unsure about how "apreq_body_get" could fit into that
scheme. "apreq_get_body" somehow conflicts with "apreq_body" because
both contain the singular form of "body".

Max

Re: deprecated attribute? / naming

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 10:42 AM 2/7/2005, Max Kellermann wrote:
>On 2005/02/07 16:52, "William A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
>> At least APR has adopted the lib_function_verb() form, at some
>> small insistence from the modperl community.  It has the very
>> nice artifact of devolving to class lib_function->verb() when
>> abstracted.
>
>ok, I'm persuaded on that. That plural in "apreq_args_get()" is also
>conforming to your standard?

I probably should have said lib_object->verb() - but yes, if it's
a collection (apreq_args or apreq_arglist) then plural works, but
arglist might be even clearer.  Whatever makes apreq more approachable
by httpd and apr developers, the more uptake I hope we get in the
community :)

Bill

Re: deprecated attribute? / naming

[Max Kellermann <ma...@duempel.org>]

On 2005/02/07 16:52, "William A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
> At least APR has adopted the lib_function_verb() form, at some
> small insistence from the modperl community.  It has the very
> nice artifact of devolving to class lib_function->verb() when
> abstracted.

ok, I'm persuaded on that. That plural in "apreq_args_get()" is also
conforming to your standard?

Max

Re: deprecated attribute? / naming

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 03:20 PM 2/6/2005, Max Kellermann wrote:
>On 2005/02/06 21:56, Joe Schaefer <jo...@sunstarsys.com> wrote:
>> Given the amount of changes, I think that's a very good idea.  So
>> anything we mark in 2.05-dev as deprecated will mean that we're
>> planning to remove these items in the 2.06 (non-developer) release,
>> ok?
>
>+1
>
>A little bit about names..
>
>I noticed you deprecated "apreq_cookie()" and replaced it by
>"apreq_jar_get()". "jar" used to be the name for the class which
>collects cookies. I would rather drop the name "jar" now in favor of
>"cookie":
>
> apr_status_t (*cookies)(apreq_env_handle_t *, const apr_table_t **);
> apreq_cookie_t *(*cookie_get)(apreq_env_handle_t *, const char *);
>
>When we're discussing the function names in apreq_env.h, what do you
>think about the following renames:
>
> apreq_args_get -> apreq_get_arg
> apreq_jar_get -> apreq_get_cookie
>
>I'm unsure about how "apreq_body_get" could fit into that
>scheme. "apreq_get_body" somehow conflicts with "apreq_body" because
>both contain the singular form of "body".

At least APR has adopted the lib_function_verb() form, at some
small insistence from the modperl community.  It has the very
nice artifact of devolving to class lib_function->verb() when
abstracted.

I'd prefer we not start backtracking twords lib_verb_function().

Bill

Re: deprecated attribute? / naming

[Joe Schaefer <jo...@sunstarsys.com>]

Max Kellermann <ma...@duempel.org> writes:

[...]

> A little bit about names..
>
> I noticed you deprecated "apreq_cookie()" and replaced it by
> "apreq_jar_get()". 

I didn't mean to "deprecate" apreq_cookie(); sorry about that.
apreq_cookie(s) should remain a part of our headers, in some form.

I would like to maintain parity between apreq_cookie_* and
apreq_param_*.  So lets drop apreq_cookie() from our exported
symbols (by inlining it); and do the same for apreq_param().  
Include the plural forms apreq_cookies() and apreq_params() as
well.

> "jar" used to be the name for the class which collects cookies. I
> would rather drop the name "jar" now in favor of "cookie":

For now, I would rather leave "jar" as-is.

>  apr_status_t (*cookies)(apreq_env_handle_t *, const apr_table_t **);
>  apreq_cookie_t *(*cookie_get)(apreq_env_handle_t *, const char *);
>
> When we're discussing the function names in apreq_env.h, what do you
> think about the following renames:
>
>  apreq_args_get -> apreq_get_arg
>  apreq_jar_get -> apreq_get_cookie

I think the rule should be apreq_$object_$method; and I think we 
should only stray from the rule when the OO pattern doesn't make 
sense. To me "args", "jar" and "body" are IMO collections, so let's 
try to think of them as (singular) objects, ok?

-- 
Joe Schaefer