Re: The weapons of mass destruction in the intl extension

Hello Tex, Wednesday, March 26, 2008, 10:22:33 PM, you wrote: > > -----Original Message----- > From: Derick Rethans [mailto:derick@php.net] > Sent: Wednesday, March 26, 2008 9:49 AM > To: Tex Texin > Cc: Marcus Boerger; Pierre Joye; php-icu@lists.zend.com; 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. Sounds good. So now everyone should have a look. And when finding something report here. If not, you'll be fine with intl. marcus Best regards, Marcus