Re: Re: ctype function (re?)naming

HOW wrote: > Well, let's start fire =8) > > I think the compression extensions should follow the same standard. > The one you proposed for bzip2 should be applied to gzip functions as well. > readgzfile -> gz_readfile (or gzreadfile), at least to keep functions names > in alphabetical order ;-) I suggested the full rename of bzip because it was very recent. Few users will have adopted it yet. I did not suggest a major rework of gzip because it is consistent internally and is in wide use. > Also, I know the gd extension follows the library API, but names are really > long and would benefit from being prefixed with img_ or gd_, img_ being my > favorite because one usually use $img = imagecreate... and not $gd = > imagecreate... But gd_ is more standard compliant as it takes the extension > name. > Indeed, this extension doesn't follow the naming convention > (imagecolorallocate should look more like gd_allocate_color) For the most part the gd is consistent - wrong but consistent - and I only wanted to fix what I thought was obviously broken. :) > Concerning the database extensions, I noticed that there are both > [db]_fieldtype and [db]_field_type for some of them. > I assume that the shorter one is to be an alias to the longer one and that > only the longer one would be documented. > Concerning DB especially, shouldn't dblist be renamed dbmlist to keep > consistent with its own family, if not underscored ? Yep, another one that slipped past me. > OCI and DB are the only database extensions without underscores. But they names are consistent within their extension. > Although Andi's suggestion is not to bother with consistent extensions, it > is probably a good idea to keep extensions "families" consistent altogether. > So, oci* functions would also gain an underscore. IMO, yes - but for the sake of fixing what is most broken with the least effort, I will have to disagree. :) > getallheaders... Two changes instead of one, but for better compliance... > get_all_headers... Too much overhead ? My vote is already cast on this one :) > Maybe DOMXML and GETTEXT functions would benefit from a complete lifting ;-) > > EXIF : read_exif_data -> exif_read_data Good eye - this should be fixed as well > gmp_clrbit -> gmp_clr_bit ? Hmmm... gmp_clear_bit ? > The gmp_ functions look odd... You have gmp_gcdext, gmp_sqrt, gmp_powm then > gmp_perfect_square > I don't have a solution for that. =8( They are new - we can do whatever is best to them. :) > In HYPERWAVE functions you have hw_connection_info then hw_deleteobject... > One of those looks wrong. > hw_errormsg -> hw_errmsg (to keep consistent with all other errmsg > functions around). Hmmm - I must have missed this one as well. > Output buffering handlers should remain consistent such as ob_[handler > type]_handler (see ob_gzhandler -> ob_gz_handler) Good eye. > I didn't quite follow the thread for the last two weeks and my intervention > may seem to be a step back from there. Just my 2cts. No worries - your feedback is valued! > >phpversion -> phpversion > > *** you meant php_version =8) <sigh> Yep > >user_error > > *** Yes, error_user would be offensive ;-) :) --zak