Re: Re: conventionabout function naming II
| From: | Zak Greant | Date: | Wed, 20 Dec 2000 05:19:15 +0000 |
| Subject: | Re: Re: conventionabout function naming II | ||
| References: | 1 | Groups: | php.dev php.doc php.qa |
| Request: | Send a blank email to php-dev+get-41893@lists.php.net to get a copy of this message | ||
Jouni Ahto wrote:
> On Tue, 19 Dec 2000, Zak Greant wrote:
>
> > Also, there was some discussion a few months ago about normalizing all
of
> > the function names.
> >
> > We have a lot of functions that do not conform to the standard. IIRC,
the
> > discussion on the phpdoc list was to create a conforming alias for each
> > non-conforming function and as time permits, document that the old names
are
> > deprecated. Then perhaps next major release or two - PHP 5 or 6 -the
old
> > names stop working.
>
> Just to note, one big problem will be the documentation. With one
> conforming to the rules and (one|two|three|...) non-conforming names, it's
> going to be a bit hard. Or at least a bit hard to use the documentation. I
> haven't seen any good solutions in DocBook XML for this. Tagging something
> as <note>... In PHP ?.--?.?, this function foo_bar_create was called
> FooBarCreate ...</note><note>... In PHP ?.?.--?, this function
> FooBarCreate was called FooBar ...</note> isn't it.
Perhaps we should have one entry under the conforming name and then have
dummy references for the non-conforming names that refer back to the main
entry.
foo_bar
void foo_bar (void)
...
Psst! Don't mention the deprecated aliases..
foobar
foobar is a deprecated alias for foo_bar.
> Not that creating macros handling
>
> PHP_FALIAS_WILL_BE_DEPRECATED_SOMEDAY(foo, bar [, ...])
> PHP_FALIAS_WILL_BE_DEPRECATED_VERY_SOON(foo, bar [, ...])
> PHP_FALIAS_WILL_BE_DEPRECATED_REALLY_SOON_NOW(foo, bar [, ...])
> PHP_FALIAS_WAS_DEPRECATED_AND_YOU_NEVER_READ_THE_WARNINGS(foo)
> PHP_FALIAS_WILL_BE_DEPRECATED_IN_PHP_5(foo, bar [, ...])
> PHP_FALIAS_WILL_BE_DEPRECATED_IN_PHP_6(foo, bar [, ...])
:D You nut bar - am I sad that you can even think of twisted things like
this. ;~>
--zak
> will be so easy either. i.e., I mean fixing PHP extensions' code and using
> those macros... not fixing the code and, for the user, not reading any
> warnings generated is a bit too easy.
>
> But, if there can be found some reasonable way to document the change of a
> functions name, I could think of using at least the first one. Especially
> if Sascha goes to the 'macro-master' mood.
>
> -- Jouni
>
> > ----- Original Message -----
> > From: "Jani Taskinen" <sniper@iki.fi>
> > To: "Andi Gutmans" <andi@zend.com>
> > Cc: "PHP Quality Assurance" <php-qa@lists.php.net>; "PHP
> > Development"
> > <php-dev@lists.php.net>
> > Sent: Tuesday, December 19, 2000 4:45 PM
> > Subject: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] convention about function
> > naming II
> >
> >
> > > On Tue, 19 Dec 2000, Andi Gutmans wrote:
> > >
> > > >I really want these name changes to make it into 4.0.4 or we'll be
left
> > > >with backwards compatibility problems when releasing 4.0.5.
> > > >Sascha, I think we should have one last RC. We will end up having to
keep
> > > >two versions of the function names which sucks.
> > >
> > > Shouldn't those socket extension's function names be changed too?
> > >
> > > --Jani
>