httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <trawi...@bellsouth.net>
Subject Re: [PATCH] 2nd draft of APR wrapper for iconv
Date Wed, 19 Apr 2000 12:55:13 GMT
Ken Coar wrote:

> Jeff Trawick wrote:
> > 
> > Beyond what was discussed on the list earlier today, I made several
> > additional changes which hopefully are acceptable:
> > 
> > 1) in honor of Ryan's new ap_cp_XXX function names, I changed:
> > 
> >    a) the name of the handle type from ap_iconv_t to ap_cp_t
> >    b) the name of the header file from apr_iconv.h to apr_cp.h
> >    c) the name of the Unix source file from
> >       lib/apr/iconv/unix/apr_iconv.c to lib/apr/cp/unix/cp.c
> 
> I hate to be a fly in the ointment, but I really am opposed
> to dropping the recognisable and meaningful 'iconv' portion
> of the names and replacing them with the non-intuitive 'cp'.
> This strikes me as a name change for no good reason (:-D)
> and I'm -1 on such a non-intuitive naming scheme because of
> readability issues.

I'm real easy on this...  While I'm not tied to either "iconv" or "cp"
(or any other key term for that matter), I do like the use of the key
term throughout the set of names/symbols, as in 

  lib/apr/X/foo/X.c
  lib/apr/include/apr_X.h
  ap_X_t
  ap_X_open
  ap_X_close
  ap_X_conv_buffer
  ap_X_conv_char
  (surely other interfaces in the future)

Who wants "iconv" besides Ken?
Who wants "cp"?

> Particularly if we're using a HAVE_ICONV macro, things which
> depend on it should be named likewise.

In my view, the interface and even the skeletal infrastructure which
is in place is not tied to iconv(), so I have no similar concern.
That is simply the only implementation now.  (This would be more clear
if more of the desired infrastructure existed :) )

Have fun,

-- 
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
     http://www.geocities.com/SiliconValley/Park/9289/
          Born in Roswell... married an alien...

Mime
View raw message