Stanislav Malyshev wrote: > Hi! > >> Bottom line, being able to alias in functions the same way you can >> classes would be useful. You could also shoot yourself in the foot. >> >> You can alias in classes. You can shoot yourself in the foot with that >> as well. > > As I already noted in my response to Jochem, there's a difference > between classes and functions. With functions, the possibility of foot > injury is much higher, and possibility of any better outcome, not > available easily by other means, is much lower. We try to find a balance > here, between allowing as many things as possible and turning whole > thing into a mess where one could find no ends. I think the balance lies > where it is today - maybe dropping functions from namespaces wouldn't > upset the balance too much, even improve it, but since I feel better > allowing than not allowing I am ready to tolerate them. :) > > However, importing function names is both dangerous (clashes), bad style > (you don't really want to override global strlen, really) and > impractical (functions come in libraries, how 50 imports would look? are > you ready to maintain huge import list for every function you ever > mention in your code?). It does appear to have small convenience value - > but IMHO not nearly enough to outweight potential downsides. I'm going to have huge use lists anyway - however I think some clever class_alias use will become widespread to fake use * in libraries.
> And I'm sorry for repeating it ad nauseam, but I still don't have any > explanation why old_foo() is so much better than Old::foo(). Without > understanding that it is hard to understand why one needs to import > functions in global space. Here's a quick use case for you -> you have a group of "helper functions" for a PHP based template system. You want to have those functions in "global scope" for the template (and yes, you might want to override strlen) and no, you don't want your templates to be using static calls into namespaced functions. Thanks, Elizabeth -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
