Bernhard, wouldn't your solution impose a performance penalty and extra maintenance by forcing a bunch of PHP wrapper object calls onto everything?
I would think that the solution that I proposed would be better for performance reasons and because one doesn't have to remember to use the wrappers. In fact... if implementations of these classes are simply dropped into a directory that is autoloaded, and the user's PHP *does* have them, they will never have to be autoloaded because class_exists() will never fail, yes? So there is *zero* performance penalty for people who have real Intl. Which is as it should be. To autoload implementations of the missing Intl classes all we need is a folder in autoload.php for things that unfortunately do not have a consistent namespace or prefix... Alas, the universal autoloader understandably does not allow this as written. No prefix, no namespace, no service. (: I realize Fabien is trying to encourage good practices here, but is it worth the negative performance impact on people who don't actually need these implementations of missing "standard" classes (and perhaps functions as Lukas suggested)? (I actually did look up what would happen if you used an empty prefix. strpos() would throw an error in that situation) On Jan 25, 8:17 am, Bernhard Schussek <[email protected]> wrote: > Hi Tom, > > I basically agree. My plan is to create an interface for all of intl's > classes that we use and provide two implementations: One that uses the > intl class internally and another that imitates a subset of the intl > class's behaviour for the "en" locale. > > Example: > > NumberFormatterInterface -> outlines all methods and constants from > \NumberFormatter > NumberFormatter -> implements the above interface and uses > \NumberFormatter internally > SimpleNumberFormatter -> independent of intl, behaves like > \NumberFormatter with locale "en". Only the most important > functionality should be implemented here. > > Let me know if you want to work on this. You can sign up onto Pivotal > Tracker and grab a ticket if you like. Eriksen Costa also wants to > work on this, so you should coordinate your efforts. > > https://www.pivotaltracker.com/projects/130524 > > Cheers, > Bernhard > -- > Software Architect & Engineer > Blog:http://webmozarts.com > Twitter:http://twitter.com/webmozart -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
