Re: Re: ctype function (re?)naming

From: Date: Wed, 07 Mar 2001 00:43:08 +0000
Subject: Re: Re: ctype function (re?)naming
References: 1 2 3 4 5  Groups: php.dev php.qa 
Request: Send a blank email to php-dev+get-48116@lists.php.net to get a copy of this message
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. > 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... > > EXIF > > read_exif_data > > > exif_read_data? Yep - we should fix this... > > 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 > > 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. > > 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 ? > > 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. Thanks for the feedback Sterling! :) --zak

« previous php.dev (#48116) next »