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
RE: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
On Sun, 23 Mar 2008, Tex Texin wrote: Pierre, Marcus, et al. 1) The project started a year or so ago. A few of us from different companies had a strong need to see that PHP had international collation, formats, normalization, grapheme support, and other functions in a time frame nearer than php 6. The resulting intl extension has been out for a while, first with collation, then with some formatters. Stas made announces to the php-i18n list at least as early as July 17 (possibly earlier). The specs were posted to php-i18n and there has been discussion on the list over time. The manual documentation was announced by Stas for review to this list as well on Dec 4. So there has been opportunity for input on the specs and the project is above board. No one is deciding anything about PHP. There have been 300 downloads since Dec. so some people know about it. There have not been many requests for changes. I think the major problem is that because discussions about it happen off-list, there is not much exposure on what you're doing and thus little feedback. That's the whole problems with splitting off to a different list for something that you're targetting to include in the core. So I don't think it's that strange that there is now a large group of people being not-so-happy about what you're trying to do here. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
On Sun, 23 Mar 2008, Steph Fox wrote: Few people want this extension to be moved to core, which means: every decision about this extension is deciding anything about PHP. Those 'few people' were actually in the majority when it was put to the vote. Yes development could and should've been made public all along, but the fact remains that intl offers damn useful functionality. 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. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
On Sun, 23 Mar 2008, Stanislav Malyshev wrote: Noone is arguing about the usefulness of the extension. We are arguing about how the maintainers of the extension are about to abandon it once it reaches -stable and the fact it doesn't even try to Hannes, wtf you are talking about? Nobody even thinks about abandoning it. To make matter worse Zend is once again trying to split the community into closed enterprise discussion lists and php.net discussions. The list is open for everybody working on a project. And everything was announced and comments solicited on php-i18n too. That's not the point. The point is that discussions for something you want to put in core happen on the core list as well. More exposure - more feedback - happier people. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
On Sun, 23 Mar 2008, Lester Caine wrote: Derick Rethans wrote: On Fri, 21 Mar 2008, Pierre Joye wrote: I rather prefer to have this class (and related) within the ext/date extensions. It is the only way to have a consistent and working date/time API in php. Date/time formatting is part of this API. I've mentioned that from the beginning (and started experimenting a bit with it already as date_format_locale()), but apparently that's not the correct way. I think the question here is WHY would you want to format a date without using a date object? SO why is it wrong to have object formatting packaged with the relevant object? I may be missing something here, but if the idea is to standardise then surly we should be standardising and not creating tools for unnecessary alternatives? I'm still having to use my own Date alternative until we can finally draw a line under PHP4 compatibility - so lets not start opening more rabbit holes to compatibility :( Yeah, exactly what I'm thinking. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- 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
Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
Dammit, I sat on this record and I broke it.. :) -Andrei Pierre Joye wrote: By the way, when was this list created? Why discussions about the development of this upcoming core extension are not public and under php.net? I don't think it is a good thing and I dislike this way of working. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
On Mon, Mar 24, 2008 at 6:08 PM, Andrei Zmievski [EMAIL PROTECTED] wrote: Precisely. It was never a secret, despite someone's paranoidal proclaiments.. It was not a secret per se and someone was not paranoid, please stay polite and respectful, thank you. But, there is a huge difference between being paranoid and asking for some kind of openness. The way things are getting done lately is everything you want but open. Please point me to a post on internals announcing the creation and availability (as anyone being able to subscribe via a known form/mail). The ICU project itself was indeed announced publically here: http://news.php.net/php.i18n/1078 and as said in this announcement, I expected it to be discussed in the php-i18n list only: We intend to discuss it on the PHP Internationalization list - [EMAIL PROTECTED] I would appreciate respectful answers (thanks Tex, your post was a model of respect even if I still disagree on some part, more later, other may learn from you :). 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] Graphemes and unicode vs intl extension
Derick Rethans wrote: On Fri, 21 Mar 2008, Pierre Joye wrote: On Fri, Mar 21, 2008 at 5:35 PM, Derick Rethans [EMAIL PROTECTED] wrote: On Fri, 21 Mar 2008, Stanislav Malyshev wrote: You can't actually use the class name DateFormatter when you want pecl/intl to be in core. Date is the prefix for the already existing Date extension. I think we still can name it DateFormatter, especially if we plan (and we do, as I understand) to merge DateFormatter functions with ext/date in PHP 6, and we don't have any conflict now and we do not have any plans to have DateFormatter in ext/date (correct me if I'm wrong here). You're wrong. We can rename it later *if* it gets merged into ext/date, but you can't simply use a classname with a prefix that conflicts with something else. Merging it would most likely change API anyway. I rather prefer to have this class (and related) within the ext/date extensions. It is the only way to have a consistent and working date/time API in php. Date/time formatting is part of this API. I've mentioned that from the beginning (and started experimenting a bit with it already as date_format_locale()), but apparently that's not the correct way. I think the question here is WHY would you want to format a date without using a date object? SO why is it wrong to have object formatting packaged with the relevant object? I may be missing something here, but if the idea is to standardise then surly we should be standardising and not creating tools for unnecessary alternatives? I'm still having to use my own Date alternative until we can finally draw a line under PHP4 compatibility - so lets not start opening more rabbit holes to compatibility :( -- 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
RE: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
Pierre, Marcus, et al. 1) The project started a year or so ago. A few of us from different companies had a strong need to see that PHP had international collation, formats, normalization, grapheme support, and other functions in a time frame nearer than php 6. The resulting intl extension has been out for a while, first with collation, then with some formatters. Stas made announces to the php-i18n list at least as early as July 17 (possibly earlier). The specs were posted to php-i18n and there has been discussion on the list over time. The manual documentation was announced by Stas for review to this list as well on Dec 4. So there has been opportunity for input on the specs and the project is above board. No one is deciding anything about PHP. There have been 300 downloads since Dec. so some people know about it. There have not been many requests for changes. Several of us working on this project don't know PHP internals. We know ICU. The php-icu list was more about coordination and who was doing what, as well as Stas and others explaining PHP internals to us, more than design. There was some design discussion, usually around PHP compatibility. Most of the discussion, being logistics, wouldn't have interested anyone else. The specs are posted on php-i18n for review so the project is open. The project itself is just putting wrappers around ICU, with only a couple of functions being coded. We just mapped PHP calls to ICU functions. We aren't implementing from scratch. 2) I cannot fathom why you say that minds cannot be changed. Questions were asked and answered. The discussion is ongoing. Where is the problem? 3) I offered as much background as possible above. From here out, let's focus on the functionality and the naming conventions, etc. 4) One more note: As the specs and beta have been out for months, we thought we were near done. Also, some of the people that worked on this have to move on to other tasks. We also have a need for the intl extension and so would like to see at least a first version become available. Considering the above, please don't interpret responses that propose to put in the next version what some might consider to be enhancements, as anything other than we have run out of time and man/woman power, but need and can use what is there today. It is not an argument for providing something that isn't right, but it is reasonable to consider making available what works, and then extending further. I hope that helps. I'll add this is my personal perspective, I don't speak for Stas, Zend, others on php-icu, or anyone else for this particular topic. tex -Original Message- From: Marcus Boerger [mailto:[EMAIL PROTECTED] Sent: Saturday, March 22, 2008 2:09 PM To: Pierre Joye Cc: Derick Rethans; Stanislav Malyshev; sf.chen; Tex Texin; [EMAIL PROTECTED]; Ed Batutis; Hong,Weilin; PHP Developers Mailing List Subject: Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension snipped I don't want to start yet another rant but there is two things that rather annoy me here: 1. I never heard of this mailing list, my question about its origin and whether is public or not has been simply ignored 2. It seems that there is no way to change minds of some employee(s) of some company(ies) The 2. is annoying and we have ways to force a choice, that does not worry me too much. But 1. is yet another step in the wrong direction. In case you were speaking of [EMAIL PROTECTED], then I have to agree as that one should not be used to decide about anything in PHP. There is an official list [EMAIL PROTECTED] out there that should serve for decisions on PHP's internationalization. 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] Graphemes and unicode vs intl extension
Hi Tex On Sun, Mar 23, 2008 at 10:03 AM, Tex Texin [EMAIL PROTECTED] wrote: Pierre, Marcus, et al. 1) The project started a year or so ago. So for a whole year none of you (not even the Zend employees that should know better) thought that there maight be a coding standard that you should follow? Both for the extension itself and everything it exposes to the user. The manual documentation was announced by Stas for review to this list as well on Dec 4. And the changes requested by us still haven't been made. So there has been opportunity for input on the specs and the project is above board. No one is deciding anything about PHP. Few people want this extension to be moved to core, which means: every decision about this extension is deciding anything about PHP. 2) I cannot fathom why you say that minds cannot be changed. Questions were asked and answered. The discussion is ongoing. Where is the problem? This thread originated on [EMAIL PROTECTED] That is a big fat problem. Why didn't you use [EMAIL PROTECTED] 4) One more note: As the specs and beta have been out for months, we thought we were near done. Also, some of the people that worked on this have to move on to other tasks. We also have a need for the intl extension and so would like to see at least a first version become available. Considering the above, please don't interpret responses that propose to put in the next version what some might consider to be enhancements, as anything other than we have run out of time and man/woman power, but need and can use what is there today. So what you are saying is everyone working on the extension are simply waiting for the 1.0.0-stable release before they move on and will never look back? Thats awesome and the most important reason why this extension cannot go into core. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
Hello Tex, Sunday, March 23, 2008, 10:03:15 AM, you wrote: [...] Several of us working on this project don't know PHP internals. This sounds extremely unprofessional and ignorant. And especially shows that you do not at all care for PHP. If I work with something I usually try to get an understaning first. If I work on Open Source project I usually first get involved in its communication channel. [...] 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] Graphemes and unicode vs intl extension
Hello Hannes, Sunday, March 23, 2008, 12:43:20 PM, you wrote: Hi Tex On Sun, Mar 23, 2008 at 10:03 AM, Tex Texin [EMAIL PROTECTED] wrote: Pierre, Marcus, et al. 1) The project started a year or so ago. So for a whole year none of you (not even the Zend employees that should know better) thought that there maight be a coding standard that you should follow? Both for the extension itself and everything it exposes to the user. The manual documentation was announced by Stas for review to this list as well on Dec 4. And the changes requested by us still haven't been made. So there has been opportunity for input on the specs and the project is above board. No one is deciding anything about PHP. Few people want this extension to be moved to core, which means: every decision about this extension is deciding anything about PHP. 2) I cannot fathom why you say that minds cannot be changed. Questions were asked and answered. The discussion is ongoing. Where is the problem? This thread originated on [EMAIL PROTECTED] That is a big fat problem. Why didn't you use [EMAIL PROTECTED] 4) One more note: As the specs and beta have been out for months, we thought we were near done. Also, some of the people that worked on this have to move on to other tasks. We also have a need for the intl extension and so would like to see at least a first version become available. Considering the above, please don't interpret responses that propose to put in the next version what some might consider to be enhancements, as anything other than we have run out of time and man/woman power, but need and can use what is there today. So what you are saying is everyone working on the extension are simply waiting for the 1.0.0-stable release before they move on and will never look back? Thats awesome and the most important reason why this extension cannot go into core. I agree. Given the circumstances we encountered just now, I do not think that pecl/intl is in any condition to be put into core. Johannes, what do you think, should we change the 5.3 wiki? 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] Graphemes and unicode vs intl extension
Hey Hannes, Few people want this extension to be moved to core, which means: every decision about this extension is deciding anything about PHP. Those 'few people' were actually in the majority when it was put to the vote. Yes development could and should've been made public all along, but the fact remains that intl offers damn useful functionality. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
On Sun, Mar 23, 2008 at 2:37 PM, Steph Fox [EMAIL PROTECTED] wrote: Hey Hannes, Few people want this extension to be moved to core, which means: every decision about this extension is deciding anything about PHP. Those 'few people' were actually in the majority when it was put to the vote. Yes development could and should've been made public all along, but the fact remains that intl offers damn useful functionality. Noone is arguing about the usefulness of the extension. We are arguing about how the maintainers of the extension are about to abandon it once it reaches -stable and the fact it doesn't even try to follow our coding standards. To make matter worse Zend is once again trying to split the community into closed enterprise discussion lists and php.net discussions. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
I should have said when we started we didn't know PHP internals. We certainly do now. My point was that the info discussed the list wouldn't have been of interest to most. -Original Message- From: Marcus Boerger [mailto:[EMAIL PROTECTED] Sent: Sunday, March 23, 2008 6:27 AM To: Tex Texin Cc: Pierre Joye; [EMAIL PROTECTED]; PHP Developers Mailing List Subject: Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension Hello Tex, Sunday, March 23, 2008, 10:03:15 AM, you wrote: [...] Several of us working on this project don't know PHP internals. This sounds extremely unprofessional and ignorant. And especially shows that you do not at all care for PHP. If I work with something I usually try to get an understaning first. If I work on Open Source project I usually first get involved in its communication channel. [...] 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] Graphemes and unicode vs intl extension
The first thing we did was look at the coding standard. Stas explained the reason we chose the naming we did. Having to work on other tasks is not abandonment. It reflects that we also have other reponsibilities. Can you be specific about which requests you think should still be made? So far the open item is the naming convention. Is that it? The extension gives a lot of capapbility to php 5.2 and 5.3. But working in the existing release does constrain how we approach it. -Original Message- From: Hannes Magnusson [mailto:[EMAIL PROTECTED] Sent: Sunday, March 23, 2008 4:43 AM To: Tex Texin Cc: Marcus Boerger; Pierre Joye; [EMAIL PROTECTED]; PHP Developers Mailing List Subject: Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension Hi Tex On Sun, Mar 23, 2008 at 10:03 AM, Tex Texin [EMAIL PROTECTED] wrote: Pierre, Marcus, et al. 1) The project started a year or so ago. So for a whole year none of you (not even the Zend employees that should know better) thought that there maight be a coding standard that you should follow? Both for the extension itself and everything it exposes to the user. The manual documentation was announced by Stas for review to this list as well on Dec 4. And the changes requested by us still haven't been made. So there has been opportunity for input on the specs and the project is above board. No one is deciding anything about PHP. Few people want this extension to be moved to core, which means: every decision about this extension is deciding anything about PHP. 2) I cannot fathom why you say that minds cannot be changed. Questions were asked and answered. The discussion is ongoing. Where is the problem? This thread originated on [EMAIL PROTECTED] That is a big fat problem. Why didn't you use [EMAIL PROTECTED] 4) One more note: As the specs and beta have been out for months, we thought we were near done. Also, some of the people that worked on this have to move on to other tasks. We also have a need for the intl extension and so would like to see at least a first version become available. Considering the above, please don't interpret responses that propose to put in the next version what some might consider to be enhancements, as anything other than we have run out of time and man/woman power, but need and can use what is there today. So what you are saying is everyone working on the extension are simply waiting for the 1.0.0-stable release before they move on and will never look back? Thats awesome and the most important reason why this extension cannot go into core. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
So for a whole year none of you (not even the Zend employees that should know better) thought that there maight be a coding standard that you should follow? We followed the coding standard. Coding standard never says there should be single prefix per extension and this prefix should be extension name. And the changes requested by us still haven't been made. If you know of any change that wasn't made, please send it to me. We talked a lot about the manual - and the fact that there was no any standard about how to document such extensions and I had to redo it anew about 3 times because nobody could give me definitive docs about how to do it - but I'm ok with that, that'd normal growth process. But if you have problems there - please do tell, and using normall process that we used to have. Few people want this extension to be moved to core, which means: every decision about this extension is deciding anything about PHP. The people then need to take part in the discussion, when invited. We can not have people silent for the whole length of discussion and implementation - which btw was repeatedly announced and comments solicited, and also beta was published, etc. - but then close to release come and say ok, we like it other way, redo everything. This thread originated on [EMAIL PROTECTED] That is a big fat problem. Why didn't you use [EMAIL PROTECTED] Because php-icu is a working list. If you want to work on the project - and I mean really work, not just saying it cannot go into core - you are welcome, please state in which areas you want to contribute and we'll discuss 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] Graphemes and unicode vs intl extension
Noone is arguing about the usefulness of the extension. We are arguing about how the maintainers of the extension are about to abandon it once it reaches -stable and the fact it doesn't even try to Hannes, wtf you are talking about? Nobody even thinks about abandoning it. To make matter worse Zend is once again trying to split the community into closed enterprise discussion lists and php.net discussions. The list is open for everybody working on a project. And everything was announced and comments solicited on php-i18n 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
Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
On Sun, Mar 23, 2008 at 8:30 PM, Tex Texin [EMAIL PROTECTED] wrote: The first thing we did was look at the coding standard. OK. Well done then. I guess I was just very unlucky picking locale/locale_methods.c to view then. Stas explained the reason we chose the naming we did. Which is great. But you don't think it would have been better to decide this collaboratively in the open rather then on your enterprise 8-16 mailinglists? If it had been we wouldn't be having this discussion now. (btw; why are you replying to these mails today? I find it very odd, but you definitely deserve a cookie for it! :D) Having to work on other tasks is not abandonment. It reflects that we also have other reponsibilities. And you replying on a Sunday, easter even, is awesome. But it is still scary thought you won't be actively around to follow bug reports or feature requests or whatever. As you know very few (if any) on this list have any clue on what you guys have been discussing or working on in your offlist talks. Can you be specific about which requests you think should still be made? So far the open item is the naming convention. Is that it? Is this a reply to The manual documentation was announced by Stas for review to this list as well on Dec 4. And the changes requested by us still haven't been made. ? If so, the DateFormatter documentation is one thing. File naming convention is another... Ouh, and btw: Please don't top-post again. That request is stated very clearly in our mailinglist rules. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
Those 'few people' were actually in the majority when it was put to the vote. Yes development could and should've been made public all along, but the fact remains that intl offers damn useful functionality. It was and is public. For heaven's sake, APIs are in the manual! Not counting the announcements on all the list - and absolutely ZERo interest from Marcus or Pierre in the topic then, and I remember no complaint from Hannes on the names either. Just as it becomes usual mode of operation here, certain people ignored it all along and then woke up and acted all surprised. There was no secret and *EVERYTHING* was announced. -- 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] Graphemes and unicode vs intl extension
-Original Message- From: Hannes Magnusson [mailto:[EMAIL PROTECTED] Sent: Sunday, March 23, 2008 1:31 PM To: Tex Texin Cc: Marcus Boerger; Pierre Joye; [EMAIL PROTECTED]; PHP Developers Mailing List Subject: Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension On Sun, Mar 23, 2008 at 8:30 PM, Tex Texin [EMAIL PROTECTED] wrote: The first thing we did was look at the coding standard. OK. Well done then. I guess I was just very unlucky picking locale/locale_methods.c to view then. == Tex that was among the first modules we wrote. But I don't think you have said what is not compliant with the standard. My suggestion is to file a bug against the intl extension so we can track issues and so they don't get lost in these email threads. Stas explained the reason we chose the naming we did. Which is great. But you don't think it would have been better to decide this collaboratively in the open rather then on your enterprise 8-16 mailinglists? If it had been we wouldn't be having this discussion now. (btw; why are you replying to these mails today? I find it very odd, but you definitely deserve a cookie for it! :D) === Tex The api was posted and open for review and collaboration, so no I don't think the existence of another list made a difference. I guess I shouldn't have phone discussions or beers with anyone working on php either so I don't risk having a non-collaborative discussion somewhere. Stas was doing a great job explaining and I didn't have a need to say more. I offered the info on the project history to try and clarify the one point. I would take the cookie but then people would accuse us of not being open and having some secret desire to topple PHP. Having to work on other tasks is not abandonment. It reflects that we also have other reponsibilities. And you replying on a Sunday, easter even, is awesome. But it is still scary thought you won't be actively around to follow bug reports or feature requests or whatever. As you know very few (if any) on this list have any clue on what you guys have been discussing or working on in your offlist talks. === Tex This is a volunteer effort to solve a problem that PHP does not have sufficient internationalization. If the volunteers need to make a lifelong commitment to support the code, then maybe we should withdraw the submission. If you look at what we did, it is just a wrapper around ICU. There isn't a lot to decide. There isn't a lot of code. There isn't a lot to worry about for support going forward either. I think it would be better for people to stop expressing theoretical concerns for conspiracy and secrecy, maintenance problems, and the like, and look at the code and doc and state precisely and constructively what should be changed, file a bug report against the intl extension and let's move forward. Can you be specific about which requests you think should still be made? So far the open item is the naming convention. Is that it? Is this a reply to The manual documentation was announced by Stas for review to this list as well on Dec 4. And the changes requested by us still haven't been made. ? If so, the DateFormatter documentation is one thing. File naming convention is another... === Tex what is wrong with the DateFormatter doc? Please submit a bug. Filenaming is being discussed. Personally, I am not convinced there is a problem or a need to change it and in fact I think the current names are better than prefixing the quite extraneous Intl which adds no value and reduces the readability of the code. But if there enough people who feel strongly... Ouh, and btw: Please don't top-post again. That request is stated very clearly in our mailinglist rules. = Tex ugh. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
On Fri, 21 Mar 2008, Pierre Joye wrote: On Fri, Mar 21, 2008 at 5:35 PM, Derick Rethans [EMAIL PROTECTED] wrote: On Fri, 21 Mar 2008, Stanislav Malyshev wrote: You can't actually use the class name DateFormatter when you want pecl/intl to be in core. Date is the prefix for the already existing Date extension. I think we still can name it DateFormatter, especially if we plan (and we do, as I understand) to merge DateFormatter functions with ext/date in PHP 6, and we don't have any conflict now and we do not have any plans to have DateFormatter in ext/date (correct me if I'm wrong here). You're wrong. We can rename it later *if* it gets merged into ext/date, but you can't simply use a classname with a prefix that conflicts with something else. Merging it would most likely change API anyway. I rather prefer to have this class (and related) within the ext/date extensions. It is the only way to have a consistent and working date/time API in php. Date/time formatting is part of this API. I've mentioned that from the beginning (and started experimenting a bit with it already as date_format_locale()), but apparently that's not the correct way. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
On Sat, Mar 22, 2008 at 6:57 PM, Derick Rethans [EMAIL PROTECTED] wrote: On Fri, 21 Mar 2008, Pierre Joye wrote: On Fri, Mar 21, 2008 at 5:35 PM, Derick Rethans [EMAIL PROTECTED] wrote: On Fri, 21 Mar 2008, Stanislav Malyshev wrote: You can't actually use the class name DateFormatter when you want pecl/intl to be in core. Date is the prefix for the already existing Date extension. I think we still can name it DateFormatter, especially if we plan (and we do, as I understand) to merge DateFormatter functions with ext/date in PHP 6, and we don't have any conflict now and we do not have any plans to have DateFormatter in ext/date (correct me if I'm wrong here). You're wrong. We can rename it later *if* it gets merged into ext/date, but you can't simply use a classname with a prefix that conflicts with something else. Merging it would most likely change API anyway. I rather prefer to have this class (and related) within the ext/date extensions. It is the only way to have a consistent and working date/time API in php. Date/time formatting is part of this API. I've mentioned that from the beginning (and started experimenting a bit with it already as date_format_locale()), but apparently that's not the correct way. I don't want to start yet another rant but there is two things that rather annoy me here: 1. I never heard of this mailing list, my question about its origin and whether is public or not has been simply ignored 2. It seems that there is no way to change minds of some employee(s) of some company(ies) The 2. is annoying and we have ways to force a choice, that does not worry me too much. But 1. is yet another step in the wrong direction. 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] Graphemes and unicode vs intl extension
Hello Pierre, Saturday, March 22, 2008, 10:01:31 PM, you wrote: On Sat, Mar 22, 2008 at 6:57 PM, Derick Rethans [EMAIL PROTECTED] wrote: On Fri, 21 Mar 2008, Pierre Joye wrote: On Fri, Mar 21, 2008 at 5:35 PM, Derick Rethans [EMAIL PROTECTED] wrote: On Fri, 21 Mar 2008, Stanislav Malyshev wrote: You can't actually use the class name DateFormatter when you want pecl/intl to be in core. Date is the prefix for the already existing Date extension. I think we still can name it DateFormatter, especially if we plan (and we do, as I understand) to merge DateFormatter functions with ext/date in PHP 6, and we don't have any conflict now and we do not have any plans to have DateFormatter in ext/date (correct me if I'm wrong here). You're wrong. We can rename it later *if* it gets merged into ext/date, but you can't simply use a classname with a prefix that conflicts with something else. Merging it would most likely change API anyway. I rather prefer to have this class (and related) within the ext/date extensions. It is the only way to have a consistent and working date/time API in php. Date/time formatting is part of this API. I've mentioned that from the beginning (and started experimenting a bit with it already as date_format_locale()), but apparently that's not the correct way. I don't want to start yet another rant but there is two things that rather annoy me here: 1. I never heard of this mailing list, my question about its origin and whether is public or not has been simply ignored 2. It seems that there is no way to change minds of some employee(s) of some company(ies) The 2. is annoying and we have ways to force a choice, that does not worry me too much. But 1. is yet another step in the wrong direction. In case you were speaking of [EMAIL PROTECTED], then I have to agree as that one should not be used to decide about anything in PHP. There is an official list [EMAIL PROTECTED] out there that should serve for decisions on PHP's internationalization. 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] Graphemes and unicode vs intl extension
Hi Marcus, On Sat, Mar 22, 2008 at 10:09 PM, Marcus Boerger [EMAIL PROTECTED] wrote: Hello Pierre, In case you were speaking of [EMAIL PROTECTED], then I have to agree as that one should not be used to decide about anything in PHP. There is an official list [EMAIL PROTECTED] out there that should serve for decisions on PHP's internationalization. Wait, I really hope that nothing will be decided about PHP on this hidden list. However that does not make feel any better. Why this list is private or hidden? If there is discussions about PHP future (ICU *IS* php future), it must be done under php.net and publically (I mean must and not should/could). 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] Graphemes and unicode vs intl extension
I admit to being unclear on why DateFormatter conflicts with Date. I'll have to read the manuals later. Seems rather limiting if all names beginning with Date are now verboten. That said: A) Derick, Shifu, Can you (or anyone) demonstrate the name conflict? I think it should have been caught by testing if it exists. I'd like to reproduce the problem. B) Name change proposals: 1) DatetimeFormatter 2) IntlDateFormatter 3) TheOtherDateFormatter ;-) 4) ICUDateFormatter If possible, I would like to confirm that there is a conflict problem or not today, and if there is agree on the name change today. tex -Original Message- From: Derick Rethans [mailto:[EMAIL PROTECTED] Sent: Friday, March 21, 2008 9:35 AM To: Stanislav Malyshev Cc: sf.chen; Tex Texin; [EMAIL PROTECTED]; 'Ed Batutis'; 'Hong,Weilin'; PHP Developers Mailing List Subject: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension On Fri, 21 Mar 2008, Stanislav Malyshev wrote: You can't actually use the class name DateFormatter when you want pecl/intl to be in core. Date is the prefix for the already existing Date extension. I think we still can name it DateFormatter, especially if we plan (and we do, as I understand) to merge DateFormatter functions with ext/date in PHP 6, and we don't have any conflict now and we do not have any plans to have DateFormatter in ext/date (correct me if I'm wrong here). You're wrong. We can rename it later *if* it gets merged into ext/date, but you can't simply use a classname with a prefix that conflicts with something else. Merging it would most likely change API anyway. But if you have a better name for it - please propose it. Something that does not start with Date. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
On Fri, Mar 21, 2008 at 6:01 PM, Tex Texin [EMAIL PROTECTED] wrote: I admit to being unclear on why DateFormatter conflicts with Date. I'll have to read the manuals later. Seems rather limiting if all names beginning with Date are now verboten. That said: A) Derick, Shifu, Can you (or anyone) demonstrate the name conflict? I think it should have been caught by testing if it exists. I'd like to reproduce the problem. B) Name change proposals: 1) DatetimeFormatter 2) IntlDateFormatter 3) TheOtherDateFormatter ;-) 4) ICUDateFormatter Classess and functions should be prefixed with the extension name according to our naming convention. All functions in pecl/intl should therefore be named intl_foobar() and classes intlFooBar in theory. See ext/date, ext/spl, ext/zip and others for more concrete examples, preferably after reading http://no.php.net/reST/php-src/CODING_STANDARDS -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
On Fri, 21 Mar 2008, Tex Texin wrote: I admit to being unclear on why DateFormatter conflicts with Date. I'll have to read the manuals later. Seems rather limiting if all names beginning with Date are now verboten. That said: A) Derick, Shifu, Can you (or anyone) demonstrate the name conflict? I think it should have been caught by testing if it exists. I'd like to reproduce the problem. It's not only an issue for classes starting with Date actually. It's in the CODING_STANDARDS: http://cvs.php.net/viewvc.cgi/php-src/CODING_STANDARDS?view=annotate#l152 Classes should be given descriptive names. Avoid using abbreviations where possible. Each word in the class name should start with a capital letter, without underscore delimiters (CampelCaps starting with a capital letter). The class name should be prefixed with the name of the 'parent set' (e.g. the name of the extension). In this case, all of the classes in pecl/intl should start with Intl. The reason for this is to not ever have conflicts between different extensions. B) Name change proposals: 1) DatetimeFormatter 2) IntlDateFormatter Which is option 2. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- 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
Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
All functions in pecl/intl should therefore be named intl_foobar() and classes intlFooBar in theory. Well, intl module as I mentioned is a bit different - it has functional parts which could be in fact separate extensions, but for practical reasons aren't. So leaving aside the collision with date, do you think it's be ok to have msgfmt_*, numfmt_* etc. prefixes? -- 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] Graphemes and unicode vs intl extension
On Fri, Mar 21, 2008 at 5:35 PM, Derick Rethans [EMAIL PROTECTED] wrote: On Fri, 21 Mar 2008, Stanislav Malyshev wrote: You can't actually use the class name DateFormatter when you want pecl/intl to be in core. Date is the prefix for the already existing Date extension. I think we still can name it DateFormatter, especially if we plan (and we do, as I understand) to merge DateFormatter functions with ext/date in PHP 6, and we don't have any conflict now and we do not have any plans to have DateFormatter in ext/date (correct me if I'm wrong here). You're wrong. We can rename it later *if* it gets merged into ext/date, but you can't simply use a classname with a prefix that conflicts with something else. Merging it would most likely change API anyway. I rather prefer to have this class (and related) within the ext/date extensions. It is the only way to have a consistent and working date/time API in php. Date/time formatting is part of this API. As I can understand the need to have one single extension in this phase (or the early stage), it would make sense to think about integrating part of the ICU with the existing PHP extension or features. By the way, when was this list created? Why discussions about the development of this upcoming core extension are not public and under php.net? I don't think it is a good thing and I dislike this way of working. 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
[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] Graphemes and unicode vs intl extension
Hi! I rather prefer to have this class (and related) within the ext/date extensions. It is the only way to have a consistent and working date/time API in php. Date/time formatting is part of this API. That'd be kind of hard to do because it uses ICU infrastructure, which would create dependency from ext/date (used by virtually everybody) to ext/intl (used by much less people and requiring ICU library). As I can understand the need to have one single extension in this phase (or the early stage), it would make sense to think about integrating part of the ICU with the existing PHP extension or features. We do it in PHP 6. However this extension (ext/intl) need to work with 5.2, and integrating ICU in 5.2 doesn't seem a good idea to me. -- 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] Graphemes and unicode vs intl extension
Hello Stanislav, no, instead I think everything in those exts should have intl_ or Intl as prefix. That works for Spl and SplTypes pretty well where I use Spl prefix in SplTypes as well. marcus Friday, March 21, 2008, 6:52:52 PM, you wrote: All functions in pecl/intl should therefore be named intl_foobar() and classes intlFooBar in theory. Well, intl module as I mentioned is a bit different - it has functional parts which could be in fact separate extensions, but for practical reasons aren't. So leaving aside the collision with date, do you think it's be ok to have msgfmt_*, numfmt_* etc. prefixes? -- 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
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] Graphemes and unicode vs intl extension
no, instead I think everything in those exts should have intl_ or Intl as prefix. That works for Spl and SplTypes pretty well where I use Spl prefix in SplTypes as well. Well, in date manual as I can see there are 2 prefixes: date_ and timezone_. And in SPL there are non-prefixed iterators, ArrayObject, iterator_count, etc. But that's less important that this question - is the name intl_numfmt_parse_currency in any way less prone to naming conflict than numfmt_parse_currency? I don't think so. And intl name is quite non-descriptive, so we don't gain much by adding it. As I said, date and number formatter could be separate extensions, they are together only for practical purposes of distribution, so stuffing them into same namespace doesn't seem reasonable for me. They do each have unique prefix, which does not infringe on any other extension, so I think it should be enough... -- 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] Graphemes and unicode vs intl extension
Hello Stanislav, Friday, March 21, 2008, 7:31:59 PM, you wrote: no, instead I think everything in those exts should have intl_ or Intl as prefix. That works for Spl and SplTypes pretty well where I use Spl prefix in SplTypes as well. Well, in date manual as I can see there are 2 prefixes: date_ and timezone_. And in SPL there are non-prefixed iterators, ArrayObject, iterator_count, etc. Yes we are aware of this. And we kept it this way mostly for BC reaons as discussions were started by these two extensions and unfortunately too late. Or we have special exceptions listed in CODING_STANDARDS (at least I hope we listed all). But that's less important that this question - is the name intl_numfmt_parse_currency in any way less prone to naming conflict than numfmt_parse_currency? I don't think so. And intl name is quite non-descriptive, so we don't gain much by adding it. Then the name of the extension is wrong. As I said, date and number formatter could be separate extensions, they are together only for practical purposes of distribution, so stuffing them into same namespace doesn't seem reasonable for me. They do each have unique prefix, which does not infringe on any other extension, so I think it should be enough... But this way we get an overflow of prefixes. And I'd prefer grouped functionality to share prefixes. 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
Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
Hi, Stanislav Malyshev wrote: All functions in pecl/intl should therefore be named intl_foobar() and classes intlFooBar in theory. Well, intl module as I mentioned is a bit different - it has functional parts which could be in fact separate extensions, but for practical reasons aren't. So leaving aside the collision with date, do you think it's be ok to have msgfmt_*, numfmt_* etc. prefixes? As long time PHP user I was very happy about the coding-standards to prefix functions/classes with the corresponding ext-name, really. As user (for some reasons) I prefer the prefixing with intl_. However, as lurker, I know, my vote doesn't count ;-) Kind Regards Friedhelm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
Then the name of the extension is wrong. Well, that's what we could do. You are welcome to propose a better one :) But this way we get an overflow of prefixes. And I'd prefer grouped functionality to share prefixes. We don't have any limit on how many prefixes we can have, so I don't see any reason why extension can't have more than one, provided it's warranted by it's structure - i.e. having more than one distinct functional module. Again, the practical purpose of this is to avoid naming conflicts. I think we can agree numfmt_*, etc. achieve that. And actually CODING_STANDARDS never says function prefix should be extension name - it only says functions should use prefixes and provides extension name as an example of class prefix. What it actually says is: If they are part of a parent set of functions, that parent should be included in the user function name, and should be clearly related to the parent program or function family. This should be in the form of parent_*: I think right now intl/ extension conforms to it fully - each parent set has its own prefix. -- 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
