I totally agree with Josh, same argument - resolving to global resources should be by default, so we don't need to rewrite a lot of code, witch we want to namespace. Namespaced functions will be called far less in code then global ones.
2008/10/28 Josh <[EMAIL PROTECTED]> > Hey, > > I think that using \ to prefix global symbols in namespaces would be > quite dumb. It would feel counter-intuitive because then if your > coding you would need to think to yourself, "am I in a namespace?", > thus increasing the chance for simple errors. It would be incedibly > annoying when writing php libraries, because all of the library code > would be in namespaces, so you would need to prefix \ in front of > _every single_ function call in your library. > > A change like this will also partially break code - rather than users > just appending 'namespace' at the beginning of every code file, they > would also need to update all global function calls. History has shown > us that breaking code (e.g. PHP4 - PHP5) slows adoption of new > versions. > > Just my 2 cents. > Josh > > > On Mon, Oct 27, 2008 at 10:06 PM, Stan Vassilev | FM > <[EMAIL PROTECTED]> wrote: > > Hi, > > > > > > Now that we have a separator, it's time to clarify what happened to the > resolution order for functions and classes, which if I read Greg's messages, > is still not clearly defined. > > > > 1) I think we've established that autoloading + fallback for classes is > unworkable, as it either causes excessive autoload triggering, or > alternatively allows internal classes to override unloaded but > to-be-autoloaded namespaced classes. Then why is it still under > consideration? > > > > 2) Making the backslash optional for internal functions means popular > drop-in replacements for internal functions and extensions in global space, > which work today, will break in a namespace, examples: libcurlemu. Also > check any comments on PECL functions on php.net, and you'll see a myriad > of drop-in replacements people use today. > > > > Also, for those who want to automatically convert their internal > functions to backslash prefix for use in namespaces, you can use this quick > snippet I wrote (works in 5.2.x too): > > > > http://pastebin.com/f13125acd > > > > I don't make guarantees it's perfect, but it can be improved and given to > people as a porting aid. > > > > Opinions about how disruptive a mandatory backslash for global symbols > *in namespaces* would be, are welcome. Keep in mind that making the > backslash optional will lead to code breakage (such as for above drop-in > replacements, class autoloading etc.) and slower performance (runtime > resolution of function calls). > > > > Think of it as file paths. When you're inside a directory you need to > prefix your path with "/" (eg "\") to refer to the root, but you don't need > to do that when you're in the root directory. > > > > Regards, > > Stan Vassilev > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
