Re: XML_Xpath

From: Date: Fri, 30 Jan 2004 09:32:25 +0000
Subject: Re: XML_Xpath
References: 1 2 3 4 5  Groups: php.pear.qa 
Request: Send a blank email to pear-qa+get-434@lists.php.net to get a copy of this message
Pierre-Alain Joye wrote:
On Fri, 30 Jan 2004 10:17:37 +0100 smith@backendmedia.com (Lukas Smith) wrote:
Some people dont want to change their code for php5, eventhough php5 has much much besster xpath support. And some people need their code to work in both php4 and php5. Where ever possible (without forcing major redesign or performance degration - in which case it would be optional) I would like to see php5 support for all PEAR packages (regardless if there is equivalent functionality already natively supported in php5).
I do not agree. We cannot force maintainers to support php5. However if a package is useless in php5, I do not see a reason to port it to php5. Let the users really migrate to php5 and do not keep old codes for years.
You are misreading what I said: I said if its a minimal effort to support php5 they should do it. If not its their choice.
If the required fixes are small (ie references, definition,...) it is obviously not bad to apply them.
Which is exactly what I said.
In the case of XML_XPath, that will bloat the whole thing if you want to have a real php5 support and php4 support.
I dont know what it takes to support php5 in xpath. It will definatly need special handling for all the get_class() calls. I dont know what more it would require. However the fact that php5 has much better native support than pear::xpath will ever provide is no reason not to fix the package for php5, if it requires minimal effort or the developer chooses to do so, without breaking BC (and degrading performance too much) for the existing php4 userbase. regards, Lukas Smith smith@backendmedia.com _______________________________ BackendMedia www.backendmedia.com berlin@backendmedia.com Linn Zwoch Smith GbR Pariser Str. 44 D-10707 Berlin Tel +49 30 83 22 50 00 Fax +49 30 83 22 50 07

« previous php.pear.qa (#434) next »