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?
We had to address a similar problem in PEAR and we currently have the
following regulation in place which is a solution which is not beautiful
either:
http://pear.php.net/group/docs/20031114-bbr.php
I guess the only advantage to using letters to denote new major versions
is that I dont know anyone else using "i" as a postfix like this. So we
are less likely to clash with a theoretically possible xmlrpc2 standard
if we were to use the more common method of appending numbers.
Also while xmlrpci is only a pecl ext for now is seems like it registers
a class called xmlrpc ("REGISTER_XMLRPCI_CLASS(xmlrpc, rpc, NULL, 0)").
I dont think this is a good idea either.
regards,
Lukas
Hi,
Lukas Smith schrieb:
Also while xmlrpci is only a pecl ext for now is seems like it registers
a class called xmlrpc ("REGISTER_XMLRPCI_CLASS(xmlrpc, rpc, NULL, 0)").
I dont think this is a good idea either.
IIRC XMLRPCi strives to be backward compatible with ext/xmlrpc...
But I agree that the "i" prefix is somewhat strange...
Stephan
http://www.php-tools.net
http://www.schst.net
http://pear.php.net
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
Well it's a good question but I'm not sure how we'd call it. XML-RPC is
already taken.
Ideas?
Andi
At 09:11 PM 3/21/2005 +0100, 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?We had to address a similar problem in PEAR and we currently have the
following regulation in place which is a solution which is not beautiful
either:
http://pear.php.net/group/docs/20031114-bbr.phpI guess the only advantage to using letters to denote new major versions
is that I dont know anyone else using "i" as a postfix like this. So we
are less likely to clash with a theoretically possible xmlrpc2 standard if
we were to use the more common method of appending numbers.Also while xmlrpci is only a pecl ext for now is seems like it registers a
class called xmlrpc ("REGISTER_XMLRPCI_CLASS(xmlrpc, rpc, NULL, 0)"). I
dont think this is a good idea either.regards,
Lukas
...
The obvious problem is:
What comes after "i"?
ii? iii? iv?
How transparent is this naming scheme to the user?
Well if it's a simple Roman Numeral system like what I've just done then
we wouldn't really have an issue (except that it assumes people know
Roman Numerals). Not sure if that's really the way you all want to go
though.
The nice thing about doing it this way: It's a distinctly different
numbering system and it just-so-happens to fit in with what we already
have. Besides I thought one of the P's in PHP was "pragmatic".
We had to address a similar problem in PEAR and we currently have the
following regulation in place which is a solution which is not
beautiful either:
http://pear.php.net/group/docs/20031114-bbr.php
Yeah that does have a few pock marks :-/
As another alternative you could just make it really, really obvious
that the newest version breaks BC by just shoving BC in there.
xmlrpcbc1
xmlrpcbc1.x.y
xmlrpcbc2
...
--
Teach a man to fish...
NEW? | http://www.catb.org/~esr/faqs/smart-questions.html
STFA | http://marc.theaimsgroup.com/?l=php-general&w=2
STFM | http://php.net/manual/en/index.php
STFW | http://www.google.com/search?q=php
LAZY |
http://mycroft.mozdev.org/download.html?name=PHP&submitform=Find+search+plugins
On Thu, 24 Mar 2005 06:16:03 -0500, Jason Barnett
jason.barnett@telesuite.com wrote:
...
The obvious problem is:
What comes after "i"?ii? iii? iv?
improved improved,
improved improved improved
improved very
i means improved, not "the roman numeral i".
--Wez.
Wez Furlong wrote:
On Thu, 24 Mar 2005 06:16:03 -0500, Jason Barnett
jason.barnett@telesuite.com wrote:...
The obvious problem is:
What comes after "i"?ii? iii? iv?
improved improved,
improved improved improved
improved veryi means improved, not "the roman numeral i".
Well that may be have been the original intention. I have seen alot of
people suggest going with roman numerals as a way to prevent collisions
with other projects. It is an interesting coincidence. I am not aware of
any projects who has used roman numerals so it will prevent collisions.
However there is a good reason why nobody has done it:
- its ugly
- it gets verbose
- the letter "i" isnt the most readable letter .. and several "i"s next
too eachother are only making things worse.
Then again like I said it does provide a solution to work around issues
like how to deal with standards like:
POP3
IPv6
Or products like:
DB2
Doing the obvious and appending numbers will lead to problems which we
addressed in PEAR by allowing stuff like this at the developers choice:
1. FooX
2. FoovX
3. Foo_vX
Not particularily a perfect solution either.
regards,
Lukas
Wez Furlong wrote:
ii? iii? iv?
improved improved,
improved improved improved
improved veryi means improved, not "the roman numeral i".
Not to mention the ambiguity present in:
sean@iconoclast:~/php/cvs/phpdoc/en/reference$ ls -d *i *v
fribidi hwapi iconv ingres-ii mysqli nsapi w32api
S
...
The obvious problem is:
What comes after "i"?ii? iii? iv?
j? k? l?
How transparent is this naming scheme to the user?
Well if it's a simple Roman Numeral system like what I've just done then
we wouldn't really have an issue (except that it assumes people know
Roman Numerals). Not sure if that's really the way you all want to go
though.
I thought it was US-ASCII with a starting offset of 9. :)
-adam
--
adam@trachtenberg.com | http://www.trachtenberg.com
author of o'reilly's "upgrading to php 5" and "php cookbook"
avoid the holiday rush, buy your copies today!