Re: intl/resourcebundle
| From: | Stanislav Malyshev | Date: | Fri, 18 Dec 2009 01:55:25 +0000 |
| Subject: | Re: intl/resourcebundle | ||
| References: | 1 2 3 | Groups: | php.pecl.dev |
| Request: | Send a blank email to pecl-dev+get-6927@lists.php.net to get a copy of this message | ||
Hi!
Is there a preferred pastebin for php/pecl? (I will send you a diff to 1.0.3 directly)I don't think there's any special place for this. But you can put it in some public place - like github or or http://code.google.com/hosting/ - and once it's ready we could just merge it into PHP's public repos.
You're right, BUT: setAppData only works if I have ONE file. libicu can have a single .dat (multiple locales) or several .res (per locale) for ResourceBundles.That's not very good... I guess needs some thinking on how to overcome it.
I'm not sure I understand what is more expensive than what here, sorry :) What I see though is that natural pattern for this thing is to have either int-indexed or string-indexed data elements, so it might be nice if we had something like $bundle["foo"] and $bundle[42] work, not only $bundle->get("foo") etc. If there's a problem with that - fine, it can work without it, but it not, it's nice ot have it.I think this class should implement ArrayAccess - it looks natural, and I don't see how it's substantially more expensive than calling get. ItSorry for the misunderstanding: It's not ArrayAccess that's more expensive than get(); but accessing a resource (either way) is far more expensive than a simple array access - probably reading multiple files. ArrayAccess just "feels" too leightweight for me ;)
I implemented an iterator, by using numerically indexed access internally. That way, it always has a "key" to return - whereas with the native functions, no key would be available for arrays.I see. Makes sense. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com