On Mon, Aug 15, 2011 at 9:15 AM, Sebastian Krebs <krebs....@googlemail.com> wrote: > 2011/8/15 Stas Malyshev <smalys...@sugarcrm.com> > >> Hi! >> >> >> On 8/14/11 11:21 PM, Sebastian Krebs wrote: >> >>> I already made an suggestion [1], that bypass this. >>> >> >> That suggestion means you can not autoload namespaced function that >> overrides global function. Major WTF. > > > Imo overriding built-in functions is a WTF... Confusing others by changing > the behaviour of well-known functions just sounds scary. >
Stas was referring to the fact that namespaces already provides this kind of monkey-patching, of course this won't work language constructs (which is a big wtf for most users in it's own way). > However, when you really want to do this, than you can load your functions > like before > > >> Also leads to two autoload calls (one most probably resulting in exhaustive >> include path search) when autoloading a non-namespaced function. Pretty bad >> idea IMO. my idea was something similar what Sebastian suggested, to call the autoloader twice, but now I think that the best way would be to: 1, we check that the function exists in the current namespace 2, call the autoload callbacks with the absolute name (foo\bar\baz). 3, we check that the function exists in the global namespace this would of course mean that for every occasion when you forgot to put the \ for your global function calls your autoloader gets called, but that's a bad practice, and I really hope that the namespace fallback will be deprecated/removed in future versions. it had a nice promise: you can use namespaces without rewriting your whole application, but with the current implementation, thats simply not true_ - you have to put your namespace declaration into every file, included files won't inherit that. - you can't use the classname type constructors in namespaced code. so this is a valid concern, but I still think that the people who would use this feature could still live with either of the proposed solutions. I know that the bad decisions in the past won't count in this argument, but the current "namespace resolution falls back to the global namespace" is the one to blame for this shortcoming. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
