1. One user of namespaced constants & functions here... I dont like to use objects for everything. I have very few constants & functions but I would like them to remain constants & functions instead of converting them to static classes or object methods. 2. One reason against dropping ns for functions & constants is that if you drop them how you can namespace legacy (or to avoid that word, not OOP) code? This way many libraries can not be namespaced and if you have a name collision you will not be able to solve it using namespaces. 3. I prefer using\name\spaces instead of prefixing_my_classes. Here is why - I want to organize my files in a hierarchical way in the file structure. A possible solution withtout namespace using prefixes couldbe level1_level2_classname (spliting the name by _). But if I want it to be class_name? Then I have an confusion. And I personaly dislike camelCase and level1_level2_className does not works for me. Because of this I prefer to have namespaces instead of class prefixes. Then I can do name\space\class_name. 4. When you have namespace you can short_the_long_class_name used multiple times in your code importing the namespace and then using the 'shortcut'.
I put the last two just to explain why I prefer to have namespace with whatever by separator instead of dropping them. On Mon, Oct 27, 2008 at 2:29 PM, Tudor Prodan <[EMAIL PROTECTED]>wrote: > I agree with Thomas Lee, if the backslash ever gets released, it's > there forever. > > Who uses functions and variables in a namespace anyway? very few > Will that small part of the users even use namespaces? probably not > > So, why not ban these from namespaces and save all the trouble? > If however a user will want to do this the bad way, he can always use > statics. > This way all the trouble is dumped on that small part of users that, > again, will most likely not even use namespaces to begin with. > > \Tudor > > > > On Mon, Oct 27, 2008 at 2:16 PM, Alain Williams <[EMAIL PROTECTED]> wrote: > > I apologise for being silent on this issue to date (been busy), but I > feel that > > I must comment even if the decision is now 'final'. > > > > On Mon, Oct 27, 2008 at 10:38:07PM +1100, Thomas Lee wrote: > >> I disagree that PHP being a dynamic language justifies the introduction > >> of deeply unpopular syntax. I mean, PHP developers are your end users. > >> Bad past design decisions aside, you don't want to alienate your users. > >> > >> And yes, this has probably been argued in the past. Unfortunately, it > >> looks like you have people's attention *now*. > > > > Like mine. > > > > The backslash character will cause much WTF to even experienced people. > > \ is just too *magic* in all sorts of ways. > > > > Trying to interpolate into a string is one that will cause huge problems. > > > > How about :.: -- OK it is a bit longer, but is clear, it doesn't suffer > from the > > problem that ::: has (ie 2 or 3 ':'s leading to errors). I believe that > '.' and ':' > > are available on most national language keyboards. > > > > The real problem is that we have run out of extra symbols. > > > > If you don't like the suggestion above, there are many others in that > family, eg: > > > > :=: :+: :_: :-: :@: <:> <@> > > > > > > The other thing that has always puzzled me about namespaces is that they > do NOT > > include varaibles - one of the things that I would most want to wrap up > in a namespace. > > I accept that variables in a namespace would not be in $GLOBALS, but that > is no great > > loss ... if people *really* want it we could always define: > $_NAMESPACEVARS['foo:.:bar'] > > as an array of variables in namespace foo:.:bar. > > Maybe $_NAMESPACES would be an array of all namespaces that are defined. > > > > -- > > Alain Williams > > Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, > IT Lecturer. > > +44 (0) 787 668 0256 http://www.phcomp.co.uk/ > > Parliament Hill Computers Ltd. Registration Information: > http://www.phcomp.co.uk/contact.php > > Past chairman of UKUUG: http://www.ukuug.org/ > > #include <std_disclaimer.h> > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Vesselin Kenashkov developer at www.webstudiobulgaria.com
