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.
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.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
