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
--
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]
