Re: [PHP-DEV] Re: [php-icu] Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
Stanislav Malyshev wrote: Hi! 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. Great, right now 5.2 users can use intl extension from pecl, including DateFormatter. 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 You'll also need to copy error handling and charset conversion, at least. 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. Actually, the users couldn't care less in which directory the source code was located. They care about the API provided - so do you propose to provide different API? If so, which one? As for quality, I don't see what extra quality would copying this code provide. 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 :) As I already said, anybody who wants to contribute is welcome. Actually, only discussion on date (or any non-bug-related matters for that matter :) is held for now right here. If you want to move it, say, to php-i18n, I'm OK with that too. Personally I see this as another totally irrelevant side track from getting PHP6 out! *I* have a perfectly functional date system that I have no intention of changing until I *CAN* go to a stable unicode based system. Blasting 'Date' into earlier versions broke that for many of us without actually offering anything practical and as yet I see no reason to waste time changing !!! PLEASE can all this effort on YET ANOTHER VERSION OF PHP (5.3) be directed to getting a stable build of PHP6 out of the door so we can all have something to aim for. Changing and extending PHP5 yet again is distracting from getting all the PHP4 users on board, so can we please nail PHP5 down NOW and keep all this potentially nice stuff until we HAVE a new flat platform. I can see peoples arguments for not standardising on unicode but nowadays with international trade ALL of my web site activity HAS to cope with names and addresses from around the world so even ascii luddites will get caught out sometime unless they have found a way to block all overseas access :( -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [php-icu] Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
I am not so sure. I see (in the feb-04 sources) just collator, formatter, locale, msgformat and normalizer - and dateformatter that should be integrated into the Date extension to avoid issues and confusion. I'm all for integrating it in PHP 6, however I do not see how it is possible to do it in PHP 5, without causing ext/date to require ICU, which is not acceptable. However, if you want to help with this, you are most welcome. -- 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
[PHP-DEV] Re: [php-icu] Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
On Wed, Mar 26, 2008 at 8:29 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: I am not so sure. I see (in the feb-04 sources) just collator, formatter, locale, msgformat and normalizer - and dateformatter that should be integrated into the Date extension to avoid issues and confusion. I'm all for integrating it in PHP 6, however I do not see how it is possible to do it in PHP 5, without causing ext/date to require ICU, which is not acceptable. However, if you want to help with this, you are most welcome. As intl will requires it, why is it unacceptable? 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 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). 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
Re: [PHP-DEV] Re: [php-icu] Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
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
Re: [PHP-DEV] Re: [php-icu] Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
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
Re: [PHP-DEV] Re: [php-icu] Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
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 think much better solution is to make it separate entity in PHP 5 and integrated in PHP 6 (in PHP 6 we are going to integrate some parts on intl anyway - locale, probably collator too, and we already have ICU). 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? 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. If I misunderstood your proposal, please explain further. 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. -- 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
Re: [PHP-DEV] Re: [php-icu] Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
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
Re: [PHP-DEV] Re: [php-icu] Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
Hi! 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. Great, right now 5.2 users can use intl extension from pecl, including DateFormatter. 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 You'll also need to copy error handling and charset conversion, at least. 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. Actually, the users couldn't care less in which directory the source code was located. They care about the API provided - so do you propose to provide different API? If so, which one? As for quality, I don't see what extra quality would copying this code provide. 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 :) As I already said, anybody who wants to contribute is welcome. Actually, only discussion on date (or any non-bug-related matters for that matter :) is held for now right here. If you want to move it, say, to php-i18n, I'm OK with that too. -- 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
[PHP-DEV] Re: [php-icu] RE: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
In this case, all of the classes in pecl/intl should start with Intl. IntlMessageFormatter is a pretty sucky name... But maybe if we don't have another bright idea I guess that'd be the way to go. Pity we didn't figure it out earlier in the loop, but I'm guessing it should not be too hard to search/replace the class names. Now with function names I'm not sure - having intl_numfmt_format_currency is even worse. The thing is intl extension is, unlike zip, etc. actually 4 extensions in one, so to speak - it has a number of functional modules, and this number is going to grow, but they are united under the hood of kind of super-extension. That's not what happens for most of the other extensions - they usually have one functional module. I think having more that one prefix, provided it isn't the same as for any other extension, is OK for an extension, so we can still have msgfmt_, numfmt_, etc. Any comments on that? -- 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
[PHP-DEV] RE: [php-icu] RE: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
Thanks Stas. Yes, it was because the INTL extension included unrelated modules, that we opted out of the extension naming. Besides the formatters we have graphemes and unicode normalization functions. I don't see that we have an actual collision here, so I would be inclined to keep things as they are. tex -Original Message- From: Stanislav Malyshev [mailto:[EMAIL PROTECTED] Sent: Friday, March 21, 2008 10:51 AM To: Derick Rethans Cc: Tex Texin; [EMAIL PROTECTED]; PHP Developers Mailing List Subject: Re: [php-icu] RE: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension In this case, all of the classes in pecl/intl should start with Intl. IntlMessageFormatter is a pretty sucky name... But maybe if we don't have another bright idea I guess that'd be the way to go. Pity we didn't figure it out earlier in the loop, but I'm guessing it should not be too hard to search/replace the class names. Now with function names I'm not sure - having intl_numfmt_format_currency is even worse. The thing is intl extension is, unlike zip, etc. actually 4 extensions in one, so to speak - it has a number of functional modules, and this number is going to grow, but they are united under the hood of kind of super-extension. That's not what happens for most of the other extensions - they usually have one functional module. I think having more that one prefix, provided it isn't the same as for any other extension, is OK for an extension, so we can still have msgfmt_, numfmt_, etc. Any comments on that? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [php-icu] RE: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
Hello Stanislav, Friday, March 21, 2008, 6:50:53 PM, you wrote: In this case, all of the classes in pecl/intl should start with Intl. IntlMessageFormatter is a pretty sucky name... But maybe if we don't have another bright idea I guess that'd be the way to go. Pity we didn't figure it out earlier in the loop, but I'm guessing it should not be too hard to search/replace the class names. Did you experiemnt with namespaces? Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [php-icu] RE: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
Did you experiemnt with namespaces? No, the reason is ext/intl should work with 5.2. -- 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
Re: [PHP-DEV] Re: [php-icu] RE: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
Hello Stanislav, and there is no chance to wait? Friday, March 21, 2008, 7:25:44 PM, you wrote: Did you experiemnt with namespaces? No, the reason is ext/intl should work with 5.2. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [php-icu] RE: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
and there is no chance to wait? To wait for? 5.2 is out there, and there are a lot of people needing intl support. We are working on this project for almost a year now, so we want to make a release. Of course, 1.0 is not the end of story, and we are very much intending to work further, but once we have 1.0 we'd have to support the API we have (we can add new APIs of course) and have people's code that worked on 1.0 work further. As I do not foresee substantial changes in 5.2, it being stable branch, I think what we have now is what we have to work with. -- 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
