On Wed, Mar 26, 2008 at 9:38 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: > Hi! > > > > 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. > > I think making it optional in ext/date would be harder. On top of that, > optional functions in existing classes aren't really easy to work with - > they are hard to check for, it would be harder to explain people how to > enable it if missing, and it will definitely be harder to maintain.
I meant to make the DateFormatter class not available when ICU is not available. > > 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 > > Do I understand it right that you propose copying code from intl to > ext/date? I meant to duplicate the code from ext/date (where it belongs) in pecl/intl. Please notice the "pecl/intl" not php-src/ext. The goal is to provide the DateFormatter feature to php 5.2 users. > If so, I think it would be counterproductive - the code is a > well-encapsulated module, which can exist on its own, it will require > rewriting (including probably importing a set of utility functions) for > putting it into ext/date and will not provide additional function but > only code duplication. As Derick said, it should be in ext/date. I quickly reviewed the dateformat/* code and did not catch any stopping point to actually move the code in ext/date. I agree that it will add some tiny extra work but it is really worth the effort. Having the date code in one place will benefit the users, from a quality and usability point of view. > > 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+. > > We do not want to drop date formatter, especially since it is a working > code that provides function required by people. As far as I can see, it > also does not cause any problem or any conflict with anything, and > integrating it with ext/date functionally can easily be done while it is > separate from ext/date code-wise. Actually, it was initially planned - > i.e. having formatter to accept/create objects produced by ext/date - > but we didn't have resources to make it happen for now. If we wrap it > now for 1.0 release, we still can do it for 1.1. That could work as well as long as it is: - completely transparent to the users (no worry here) - team work and (very) good communication between ext/date maintainers and intl maintainers (I worry more here ;), that means ext/date maintainers should have a word/voice in intl :) 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
