Hi, On Wed, Mar 26, 2008 at 9:02 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: > Hi! > > > > As intl will requires it, why is it unacceptable? > > intl is specialized extension for people dealing with global > environments. It will be enabled only by people that really need it. > ext/date is much more general-purpose function, used by thousands of > applications that don't care at all about global calendars and other ICU > stuff. Requiring them to have ICU library and carry it around just > because they want dates, and because of the possibility that someday > someone might want to print dates both in French and Russian does not > seem like a smart move to me. > > > > If you think (you as in all of you :) that having ICU as required > > dependency in 5.3 is not acceptable, we can make it optional. That > > How? If date formatter built into ext/date, ext/date in order to build > would require ICU.
This feature can then be optional in ext/date. That should not be an issue for those not willing to use a reliable date formatting system as they are certainly not interested in intl either. > > would be bad for intl as we will not be able to rely on it. About 5.2, > > there is no clean solution but to provide the same API than the one > > available through ext/date but via pecl/intl (that does not sound too > > complicated and would solve the forward compatibility problem). > > I'm not sure what you are proposing here, could you explain? > > Just in case it is relevant, I do not think it is practical to split > code bases between 5.2 and 5.3 - unless somebody volunteers to support > these separate branches - maintaining 5 and 6 separately is work enough. > If it's irrelevant, please ignore it. You can't add code in 5.2 but you can add everything feature you wish in pecl/intl. The only extra work is an extra commit for the date related code in pecl/intl. That's not that much work (I do that for zip and gd). It will also be required if you like to continue to release intl through PECL once it is bundled (you have to do it anyway, for the 5.2 users). Also, please note that this synchronization job can be done once at release time, not on each commit. That's the only clean solution I can think about if you like to have the date formatter available for 5.2 users. But I will rather drop it for 5.2 if it is a show stopper to do it in ext/date in 5.3+. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
