Re: Clarifying the resolution rules

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 <sv_forums@fmethod.com> 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