-----Original Message----- From: Derick Rethans [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2008 9:49 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
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. Derick, I understand the concern, but it is really a quite theoretical concern. The intl extension is a PHP wrapper around ICU API. The code layer is very thin. Most of the off-list discussions were about things like how do we return errors to PHP, (what is the coding standard for this, not designing a new approach to returning errors) and bugs with different ports and status reporting on who is doing what. As we are volunteers, we needed to check if we were actually making progress or were people busy with other (unrelated) tasks, and should we rejigger the tasking. Some of the discussion was about how to make the manual documentation. There were only a few places where we discussed offering a more php-like syntax compared to ICU API. Taking advantage of arrays for example. Even there, the layer is very thin. The locales API is one of the few places where we wrote some code to simplify parsing and composing locale identifiers for PHP users. Because we wanted to meet the 5.3 release dates, and because the development proved more difficult than we orginally estimated, we scaled back on delivering some of the API originally proposed. Support for date objects was one of the items that was left out of the original plans for this release. The reason was workload and timing. It was desired, but we couldn't resource it. The project was scoped to fit into the 5.3 time frame and the goal was to just fix limitations of PHP internationalization, not to try to do everything in PHP 5, so we had a minimalistic approach. So I understand the worry, but the conjecture that there were a lot of choices and design decisions that the list should have been privy too, is just fantasy. And like the search for Weapons of Mass Destruction, there is nothing hazardous to find. So what you see is mostly a fairly obvious mapping of ICU to PHP. We posted the API to this list last year and the changes have been few. Some functions were withdrawn, some minor tweaks. If there is an issue with the extension it should be transparent by looking at the API and determining whether it meets PHP users' needs. What we did is a reflection of what ICU offers. In some cases we considered enhancing or compensating for ICU deficiencies and we generally didn't so there wouldn't be conflicts with future versions of either ICU or PHP 6. I hope that helps. I don't think I can say any more that would be convincing. If people want to believe we are a secret cabal out to undermine PHP, than ok. I don't think there is anything we need to apologize for. Whatever the worries, you can read the manual, and see the code. If you see evidence of something deleterious to PHP please point it out using the bug system. I don't think I can take the time to continue to say the off-list discussions were insignificant to this list. The doc and the code speaks for what we did. I would be glad to discuss the code and the doc. tex
