Re: Question about Namespace patch

Matthew Kavanagh wrote: > Rasmus Lerdorf wrote: >> Stanislav Malyshev wrote: >> >>> Compile-time resolution means you don't get performance penalty for >>> namespaces when you are not using it, and have very low costs when you >>> do use it. Allowing blanket imports means we don't know what "new Foo()" >>> means until it is executed - meaning we need to make extra lookups on >>> each class fetch, even if the code doesn't use namespaces at all. That's >>> only one problem with blanket imports. >>> >> >> And a fatal one in my book. For the folks arguing so passionately about >> this namespace implementation, try to consider the compiler vs. executor >> issues involved. We really need to stop the trend of pushing everything >> down into the executor. >> >> -Rasmus >> >> > The compile time vs. execution time argument may be a good one against > global import and against other crazy ideas in my head (like allowing > statements in namespaces). > > But why not allow importing namespaced functions and constants into the > global namespace? > > If this were added then "blanket import" could be left to the intrepid > and foolhardy programmer to do manually. It'd just end up being > boilerplate and if someone really objects to some extra lines they could > add an explicit fold in their editor to hide it. As long as it doesn't go into the global namespace directly. As in: namespace foo; class bar1 { ... } class bar2 { ... } import foo:* as myfoo gives you: myfoo:bar1 and myfoo:bar2 and not bar1 and bar2 directly in the global namespace. The latter is a performance killer across the board but I see no issue with the former. -Rasmus