Re: Re: ctype function (re?)naming

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