RC2RC1

php.internals

Andi Gutmans

22 years ago
Guys, I want to roll RC2RC1. There are three major changes I think we should get out of the door ASAP: - zend.ze1_compatibility_mode fix. - MT-safe crash bug. - studlyCaps changes. The only important issue I see is John's change of tiny to throw exceptions. As there's no way we will finalize our policy on exceptions, it might be the best to roll it back and release RC2. I think the fixes are too important to let them linger for too long. John, what says you? Andi

Derick Rethans

22 years ago
Hello Guys/Gals, On Tue, 13 Apr 2004, Andi Gutmans wrote:
> I want to roll RC2RC1. There are three major changes I think we should get > out of the door ASAP:
I've one other thing to propose, and that is enabling iconv by default. Now you might ask why iconv and not mbstring? Well, that's easy as the author of mbstring (Moriyoshi) thinks of moving it to PECL, out of the core. Why I think iconv should (and can) be enabled by default is: - libxml2 which we 'require', requires a working iconv implementation (for Linux this is embedded in glibc, for FreeBSD this is the iconv library, other Operating Systems of course have some form of implementation too). - conversion between charsets is getting more and more of a problem, and to support some of the larger multi-language frameworks a bit better, having an implementation in C for this is a very good thing. (There are already implementations of conversions out in PHP, which is ofcourse awfully slow) - I am not in favor of enabling things by default *at all*, but I do think it's worthwhile to do for iconv. regards, Derick

Wez Furlong

22 years ago
+1 (and it's already on by default in the win32 build). --Wez.

Ilia A.

22 years ago
On April 13, 2004 02:34 pm, Derick Rethans wrote:
> I've one other thing to propose, and that is enabling iconv by default.
+1 given that we enable xml extensions that via libxml2 use iconv, we might as well enable the iconv extension as well. Ilia

John Coggeshall

22 years ago
The change wasn't actually to make Tidy throw exceptions, but rather to throw errors instead of exceptions (until recently, Tidy would throw exceptions in either OO or procedural contexts). Although I could change Tidy to not throw exceptions, I am inclinded to leave it as is (maybe change the error code from E_ERROR to E_WARNING). It's really bothersome to me to think of these new PHP 5 OO extensions being released without throwing exceptions. There is a lot of debate as we know about when exceptions should be thrown, but I haven't heard anyone flat out say exceptions in the OO context is bad. Thus, my hope is that we can roll RC2 and re-visit this issue to come up with a long-term exceptions standard. If for some reason we can't agree to throw exceptions internally, I've got no problem reverting back to no exceptions in Tidy. John -----Original Message----- From: Andi Gutmans [mailto:andi@zend.com] Sent: Tuesday, April 13, 2004 11:39 AM To: internals@lists.php.net Subject: [PHP-DEV] RC2RC1 Guys, I want to roll RC2RC1. There are three major changes I think we should get out of the door ASAP: - zend.ze1_compatibility_mode fix. - MT-safe crash bug. - studlyCaps changes. The only important issue I see is John's change of tiny to throw exceptions. As there's no way we will finalize our policy on exceptions, it might be the best to roll it back and release RC2. I think the fixes are too important to let them linger for too long. John, what says you? Andi
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Andi Gutmans

22 years ago
Derick, Can you commit a patch so that I can roll it tomorrow? Thanks, Andi At 08:34 PM 4/13/2004 +0200, Derick Rethans wrote:

Derick Rethans

22 years ago
On Wed, 14 Apr 2004, Andi Gutmans wrote:
> Can you commit a patch so that I can roll it tomorrow?
Done. Derick