Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:15528
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <423F3C26.5090608@php.net>
Date: Mon, 21 Mar 2005 16:27:02 -0500
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: Lukas Smith <lsmith@php.net>
Cc: internals@lists.php.net
References: <20050321201142.37642.qmail@lists.php.net>
In-Reply-To: <20050321201142.37642.qmail@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: extension naming
From: cellog@php.net (Greg Beaver)

Lukas Smith wrote:
> Hi,
> 
> I guess xmlprci is following the mysqli example. I am not sure if this 
> is a good idea to have new BC breaking versions of extensions append 
> letters like "i" (aka "improved") to solve the namespace issue. So I 
> would like to bring this topic up for discussion on this list before too 
> many other extensions blindly follow this example, just because of the 
> lack of a standarized alternative.
> 
> Anyways I dont really know if anyone from php core cares about these 
> kinds of topics so just tell me to stfu before we get a needless flame.
> 
> The obvious problem is:
> What comes after "i"?
> How transparent is this naming scheme to the user?

Don't forget - extensions don't need to co-exist necessarily.  If one is 
designed to replace the old one, it's fine to conflict.

I would recommend that pecl actually look to make names more separate. 
The number solution works for PEAR because people can reasonably expect 
to use both the old and the new version of a script in the same file. 
This is not necessarily the case in PECL.

I personally think the i postfix is an excellent choice :).

Future revisions will suggest new names, sort of like the dom_xml to DOM 
extension.  No need for anything standardized, since the Makefile 
process provides a centralized location for all things anyways.

Greg