[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] ctype function (re?)naming

[Andi Gutmans]

At 02:20 PM 3/8/2001 +0100, Hellekin O. Wolf wrote:
>At 22:33 07/03/2001 +0200, Andi Gutmans wrote:
>
>>Why not bzip2_?
>
>*** Well, if bzip2_, then gzip_ !
>If gz_ then bz_ or bz2_.
>
>Am I wrong or too fastidious ?

No, because gz_ has existed for a long time. If we'd give it a name today 
we'd probably call it gzip_* but it's too late. We can do the right thing 
for bzip2.

Andi


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] ctype function (re?)naming

[Hellekin O. Wolf]

At 14:36 08/03/2001 +0100, Jani Taskinen wrote:
>On Thu, 8 Mar 2001, Hellekin O. Wolf wrote:
>
> >At 22:33 07/03/2001 +0200, Andi Gutmans wrote:
> >
> >>Why not bzip2_?
> >>
> >
> >*** Well, if bzip2_, then gzip_ !
>
>I'd prefer these. Readable is better than saving 2-3 keystrokes.
>
>--Jani
*** Man ! Please stop associating me with "saving keystrokes" : it was 
followed by a winking smiley !

Anyway, it's a good thing that we consider our first consensus about 
renaming functions, namely [ext name]_[function]_[zblah]

AFAIK, the Gzip extension is named gzip and not gz.

Zak, would you please post an updated version of the renaming scheme, 
including the last few days changes, so that we can see things more globally ?
(And refresh the thread's subject ;-)

hellekin



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] ctype function (re?)naming

[Jani Taskinen]

On Thu, 8 Mar 2001, Hellekin O. Wolf wrote:

>At 22:33 07/03/2001 +0200, Andi Gutmans wrote:
>
>>Why not bzip2_?
>>
>
>*** Well, if bzip2_, then gzip_ !

I'd prefer these. Readable is better than saving 2-3 keystrokes.

--Jani


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] ctype function (re?)naming

[Hellekin O. Wolf]

At 22:33 07/03/2001 +0200, Andi Gutmans wrote:

>Why not bzip2_?
>

*** Well, if bzip2_, then gzip_ !
If gz_ then bz_ or bz2_.

Am I wrong or too fastidious ?

hellekin


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] ctype function (re?)naming

[Zak Greant]

Andi Gutmans wrote:
> >bzerror returns an array containing the error string and error number.
>
> Maybe it should be error_info() then?

nerk? error seems sufficient to me...

> > > >>>Maybe errstr should be changed to errmsg ? (Did I say that
elsewhere ?
> >;-)
> > > >>>As the file extension is .bz2, maybe the prefix should be bz2_ as
well
> > > >>>(it's an algorithm, not a version right ?)
> >
> >bz2_ vs. bz_ ... this is a coin-toss decision.  We might run into an
> >extension in the future where bz is a good choice for the name, thought I
> >feel it is unlikely.
> >Personally, I don't *really* care - if it came to a heated discussion and
a
> >vote, I would go for bz2_... - just so that the no one could tell us "I
told
> >you so..." in the future. ;)
>
> Why not bzip2_?

Sure. :)

> It's very hard to draw the line but I tend to be in favor of readability
> vs. how many characters you need to type.

Alrighty, the disadvantage of using full names is typing speed... the
advantages are that the purpose of the function is clearer, there is no need
to attempt remember what the abbreviation for and non-native speakers can
use automated translation tools on the function names... so I guess that we
should go for readability.

--zak


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] ctype function (re?)naming

[Andi Gutmans]

At 10:20 AM 3/7/2001 -0700, Zak Greant wrote:
>Andi wrote:
>
> > At 04:34 PM 3/7/2001 +0100, Hellekin O. Wolf wrote:
> > >At 17:22 07/03/2001 +0200, Andi Gutmans wrote:
> > >
> > >>>*** What is the difference between error ad errstr ?
>
>bzerror returns an array containing the error string and error number.

Maybe it should be error_info() then?


> > >>>Maybe errstr should be changed to errmsg ? (Did I say that elsewhere ?
>;-)
> > >>>As the file extension is .bz2, maybe the prefix should be bz2_ as well
> > >>>(it's an algorithm, not a version right ?)
>
>bz2_ vs. bz_ ... this is a coin-toss decision.  We might run into an
>extension in the future where bz is a good choice for the name, thought I
>feel it is unlikely.
>Personally, I don't *really* care - if it came to a heated discussion and a
>vote, I would go for bz2_... - just so that the no one could tell us "I told
>you so..." in the future. ;)

Why not bzip2_?


> > >>How about error_message or error_string?
> > >
> > >*** Well, errmsg/errstr are everywhere else, be it in PHP or C.
> > >errno would take the lifting also... We would end with function names
>like :
> > >
> > > mysql_error_number()
> > > mysql_error_string()
> > >
> > >Looks great regarding paragraph formatting but wastes lots of keystrokes
>;-)
> >
> > It's always better to write a few extra characters if it makes your code
> > much more readable.
>
>Agreed.  We could try to save a bit of space doing /error/err/ or
>/string/str/ or /number/num/. Where do we draw the line on
>length/convenience vs. readability?

It's very hard to draw the line but I tend to be in favor of readability 
vs. how many characters you need to type.

Andi


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] ctype function (re?)naming

[Zak Greant]

Andi wrote:

> At 04:34 PM 3/7/2001 +0100, Hellekin O. Wolf wrote:
> >At 17:22 07/03/2001 +0200, Andi Gutmans wrote:
> >
> >>>*** What is the difference between error ad errstr ?

bzerror returns an array containing the error string and error number.

> >>>Maybe errstr should be changed to errmsg ? (Did I say that elsewhere ?
;-)
> >>>As the file extension is .bz2, maybe the prefix should be bz2_ as well
> >>>(it's an algorithm, not a version right ?)

bz2_ vs. bz_ ... this is a coin-toss decision.  We might run into an
extension in the future where bz is a good choice for the name, thought I
feel it is unlikely.
Personally, I don't *really* care - if it came to a heated discussion and a
vote, I would go for bz2_... - just so that the no one could tell us "I told
you so..." in the future. ;)

> >>How about error_message or error_string?
> >
> >*** Well, errmsg/errstr are everywhere else, be it in PHP or C.
> >errno would take the lifting also... We would end with function names
like :
> >
> > mysql_error_number()
> > mysql_error_string()
> >
> >Looks great regarding paragraph formatting but wastes lots of keystrokes
;-)
>
> It's always better to write a few extra characters if it makes your code
> much more readable.

Agreed.  We could try to save a bit of space doing /error/err/ or
/string/str/ or /number/num/. Where do we draw the line on
length/convenience vs. readability?

--zak





-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] ctype function (re?)naming

[Andi Gutmans]

At 04:34 PM 3/7/2001 +0100, Hellekin O. Wolf wrote:
>At 17:22 07/03/2001 +0200, Andi Gutmans wrote:
>
>>>*** What is the difference between error ad errstr ?
>>>Maybe errstr should be changed to errmsg ? (Did I say that elsewhere ? ;-)
>>>As the file extension is .bz2, maybe the prefix should be bz2_ as well 
>>>(it's an algorithm, not a version right ?)
>>
>>How about error_message or error_string?
>
>*** Well, errmsg/errstr are everywhere else, be it in PHP or C.
>errno would take the lifting also... We would end with function names like :
>
> mysql_error_number()
> mysql_error_string()
>
>Looks great regarding paragraph formatting but wastes lots of keystrokes ;-)

It's always better to write a few extra characters if it makes your code 
much more readable.

Andi


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] ctype function (re?)naming

[Hellekin O. Wolf]

At 17:22 07/03/2001 +0200, Andi Gutmans wrote:

>>*** What is the difference between error ad errstr ?
>>Maybe errstr should be changed to errmsg ? (Did I say that elsewhere ? ;-)
>>As the file extension is .bz2, maybe the prefix should be bz2_ as well 
>>(it's an algorithm, not a version right ?)
>
>How about error_message or error_string?

*** Well, errmsg/errstr are everywhere else, be it in PHP or C.
errno would take the lifting also... We would end with function names like :

 mysql_error_number()
 mysql_error_string()

Looks great regarding paragraph formatting but wastes lots of keystrokes ;-)


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] ctype function (re?)naming

[Andi Gutmans]

At 05:26 PM 3/6/2001 -0700, Zak Greant wrote:
>Derick Rethans wrote:
>[snip]
> > > 6) I think create_function() is OK. There was a long thread which
>decided
> > > upon this name. Same for function_exists().
> >
> > Can't we call it lambda()? =)
>
>That would make a sensible alias for it. :)

Nah no aliasing to this :)
This issue was closed a long time ago.
Andi


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] ctype function (re?)naming

[Zak Greant]

Waldschrott wrote:
> > Overall I think this is very good.  I have a few problems with it (all
> > prefixed with a large IMHO :)...
>
> agreeing in anything sterling mentioned, except and in addition this:
>
> >> GETTEXT
> >> bindtextdomain
> >> dcgettext
> >> dgettext
> >> gettext
> >> textdomain
>
> is there any reason not to change them?

Simplicity - the names are consistent with each other and they match the
names of the gettext C functions.

> >> 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?
>
> how? :) I tried to find some shorter names, but then you would have to
omit parts of it,
> eg.
> iis_get/set_right  (omitting server)
> iis_get/set_state  (omitting service)
> iis_remove (omitting server)
> iis_add (omitting server)
> iis_start/stop (omitting server)
> ..maybe

As lng as the abbr. don't aff. readab. ;)

> >> xslt_output_begintransform -> xslt_output_begin_transform
> >> xslt_output_endtransform -> xslt_output_end_transform
>
> xslt_begin/end_transform ?

Ditto :)

>  >> gethostbyaddr ?
>  >> gethostbyname ?
>  >> getpeername ?
>
> ok.
>
> >> socket_get_status
> >> socket_set_blocking
> >> socket_set_timeout
>
> if we name the the socket extension functions socket_* we have a
> confusion here (these functions are from standard)

We could always use sock_ ...

> >> zzip_entry_compressedsize -> ..._compressed_size
> >> zzip_entry_compressionmethod -> ..._compression_method
>
> ok.

Thanks for the feedback Andre! :)

--zak


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] ctype function (re?)naming

[Zak Greant]

Derick Rethans wrote:
[snip]
> > 6) I think create_function() is OK. There was a long thread which
decided
> > upon this name. Same for function_exists().
>
> Can't we call it lambda()? =)

That would make a sensible alias for it. :)


--zak


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] ctype function (re?)naming

[Zak Greant]

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)

 Yep

> >user_error
>
> *** Yes, error_user would be offensive ;-)

:)

--zak


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]