At 05:43 PM 3/6/2001 -0700, Zak Greant wrote:
>Sterling wrote:
> > Overall I think this is very good. I have a few problems with it (all
> > prefixed with a large IMHO :)...
>
>:)
>
> > > array_multisort -> array_multi_sort
> >
> > nah, doesn't sound as good as array_multisort, multisort should be a
>single
> > word... Its a type of sorting method, shouldn't be two different words
>
>After looking at this one again, I agree with you.
>
> > > BZ2 (Added 4.0.4)
> > > bzclose -> bz_close
> > > bzcompress -> bz_compress
> > > bzdecompress -> bz_decompress
> > > bzerrno -> bz_errno
> > > bzerror -> bz_error
> > > bzerrstr -> bz_errstr
> > > bzflush -> bz_flsuh
> > > bzopen -> bz_open
> > > bzread -> bz_read
> > > bzwrite -> bz_write
> >
> > Why leave the bcmatch functions alone, but change these?
>
>Because they are brand spanking new and we can make the follow the naming
>convention before everyone starts using them.
Yep. Let's start doing some damage. bzip2 is a very good victim.
> > The reason they're named this way is also to keep compatibility with the
> > zlib functions.
>
>Good point - perhaps a better solution would be to have compression library
>that uses switches to choose between bzip and gzip? It would be easy to
>bolt on other compression methods without having to do much additional
>documentation, etc...
You could write a PEAR script for this but I don't think it has anything to
do with our current discussion :)
> > > EXIF
> > > read_exif_data
> > >
> > exif_read_data?
>
>Yep - we should fix this...
Yep.
> > > GMP (not in manual yet)
> > > gmp_abs
> > > gmp_add
> > > gmp_and
> > > gmp_clrbit -> gmp_clr_bit ?
> >
> > this_seems_a_little_long_gmp_clrbit_i_think_might_be_better.
>
>I prefer Andi's gmp_clear_bit
hmm, so do I. Strange.... :)
> > > gmp_hamdist -> gmp_ham_dist ?
> >
> > hamdist is I believe an abbreviation for an algorithm, and a single
> > "concept" therefore it should be kept together.
>
>Ah - I was not sure, hence the ?
>
> > > gmp_sqrt -> gmp_sqrt_rem
> >
> > why that?
>
>Good catch :)
>
> > > readgzfile
> > gzreadfile?
>
>Good catch :)
>
> > > IISFUNC (Not in manual yet)
> > > iis_addserver -> iis_add_server
> > > iis_getdirsecurity -> iis_get_dir_security
> > > iis_getscriptmap -> iis_get_script_map
> > > iis_getserverbycomment -> iis_get_server_by_comment
> > > iis_getserverbypath -> iis_get_server_by_path
> > > iis_getserverright -> iis_get_server_right
> > > iis_getservicestate -> iis_get_service_state
> > > iis_removeserver -> iis_remove_server
> > > iis_setappsettings -> iis_set_app_settings
> > > iis_setdirsecurity -> iis_set_dir_security
> > > iis_setscriptmap -> iis_set_script_map
> > > iis_setserverright -> iis_set_server_right
> > > iis_startserver -> iis_start_server
> > > iis_startservice -> iis_start_service
> > > iis_stopserver -> iis_stop_server
> > > iis_stopservice -> iis_stop_service
> > >
> > hrrm. these names seem long, perhaps we can shorten them?
>
>I think that they are quite readable now - shortening them would probably
>reduce this.
I agree.
> > > msql_regcase -> msql_reg_case
> >
> > i like msql_regcase better, we shouldn't be using (IMHO prefixing all of
> > these comments, of course) underscores to seperate words per-sé, but
>rather
> > to seperate concepts.
>
>...hmmm... considering that the legibility of this can't easily be fixed
>with a change to the function name (unless we want to use
>msql_regex_case_insensitive :) - either way is fine with me.
>
> > > SABLOT
> > > xslt_closelog -> xslt_close_log
> >
> > let's leave these (openlog, closelog).
>
>Because they match openlog and close log - or is this how sablotron
>describes these features?
>
> > > xslt_create
> > > xslt_errno
> > > xslt_error
> > > xslt_fetch_result
> > > xslt_free
> > > xslt_openlog -> xslt_open_log
> > > xslt_output_begintransform -> xslt_output_begin_transform
> > > xslt_output_endtransform -> xslt_output_end_transform
> >
> > too long :)
>
>What about something like xslt_output_begin_trans ?
I think having an extra for characters which really help understand the
meaning of the function is worth it. There for I would go with Zak's
recommendation.
> > > ZEND (All of the Zend changes are wishful thinking! :)
> > > class_exists
> > > crash
> > > create_function -> func_create (or function_create)
> > > define -> constant_define
> > > defined -> constant_defined
> > > each
> > > error_reporting
> > > func_get_arg (or function_get_arg)
> > > func_get_args (or function_get_args)
> > > func_num_args (or function_num_args)
> > > function_exists -> func_exists (or function_exists)
> > > get_class
> > > get_class_methods
> > > get_class_vars
> > > get_declared_classes
> > > get_defined_functions
> > > get_defined_vars
> > > get_included_files
> > > get_object_vars
> > > get_parent_class
> > > get_required_files
> > > get_resource_type
> > > is_subclass_of
> > > leak
> > > method_exists
> > > restore_error_handler -> error_restore_handler
> > > set_error_handler -> error_set_handler
> > > strcasecmp
> > > strcmp
> > > strlen
> > > strncasecmp
> > > strncmp
> > > trigger_error -> error_trigger
> > > user_error
> > > zend_version
> > >
> > Please, NO! ;-)))
> >
> > Seriously though, I think the Zend names are fine as they are...
>
>This seems to be the general consensus so far. (Leaving the functions along
>that is...)
>
> > > ZZIPLIB
> > > zzip_close
> > > zzip_closedir -> zzip_close_dir
> >
> > no.
> >
> > closedir() --> zzip_closedir()
> >
> > I'd prefer to keep it close to the php name.
>
>Hrm... I prefer to separate things that most people percieve as being two
>words... but if I could waffle on (close|open)log, I can waffle on this. :)
>
> > > zzip_opendir -> zzip_open_dir
> >
> > same as with zzip_closedir()
> >
> > > zzip_read
> > > zzip_readdir -> zzip_read_dir
> > >
> >
> > Same as with zzip_opendir()
>
>See above.
I don't think we need to be caught in the C API loop all the time. I think
if we'd start today without knowing libc we would call it zzip_open_dir()
or something like that. The underscore makes more sense. As it is a new
extension I think we could go with that underscore. PHP abstracts C API's
and doesn't necessarily have to be the exact same thing as C.
Andi
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
