intl/resourcebundle

Hi! Having read about the new intl extension, I dearly missed support for UResourceBundle... Therefore I bit in the sour apple (german expression) and decided to finally learn about PHP/Zend internals. I propose (and have now working) the following extension to intl: class ResourceBundle -------------------- public function __construct( string $bundlename, [string $locale, bool $fallback = true] ) Open the named bundle with the given (or default) locale. Standard behaviour of libicu (and the class) is to fall back to a more generic locale (en_US -> en) if necessary. The third argument allows to prohibit this. @TODO: libicu has a quite peculiar systematic finding files. $ENV[ICU_DATA] has to be set for regular files; php_streams are currently not supported - they would have to be read into memory as a whole and the memory "given" to libicu. Better possibilities? public function get( string|int $index, [bool $fallback = true] ) Return an element from the resource bundle. The types are translated as follows: URES_STRING => string (UTF-8) URES_BINARY => string (as-is, both should change in php6 of course...) URES_INT => integer URES_INTVECTOR => auto-keyed array of ints URES_ARRAY => class ResourceBundle URES_TABLE => class ResourceBundle I decided against returning php native types in the latter two cases, as in both cases the result might be a) huge and b) deeply nested. URES_TABLE may be accessed by numerical index or key name, URES_ARRAY by index only. "top level" ResourceBundle is either of those types. The fallback parameter has the same function as on opening the ResourceBundle. It has no function whatsoever on "deeper" ResourceBundles. I decided against allowing "ArrayAccess", as the function might be expensive. It is not a simple "lookup". public function length() rather self-explanatory. As for the iterator of ResourceBundle I decided against using the libicu iterator functions, as those don't respect order of entries. URES_TABLES allow to fetch the correct key name ex post, URES_ARRAYs however don't. My current implementation does therefore traverse both types by numerical index. Well, that's it. Nice little first project ;) Would you have any inputs/wishes on the API? source diff targets to have a look? Yours sincerely Hans-Peter