# - Thread: https://externals.io/message/41380 - Original archive: https://news-web.php.net/php.internals/41380 - Started by Tudor Prodan on 2008-10-26T10:51:55+00:00 - Messages: 24 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #41380 — Tudor Prodan — 2008-10-26T10:51:55+00:00 URL: https://externals.io/message/41380#41380 Hi, PHP has to be unique, using the double colon notation would be too cliche, but if we're not respecting conventions, why not go with something more exotic? I've always liked the o with the slash trough it. The e with the horizontal colon is also pretty nice. The n with the tilde over it, it so strongly says _n_amespace. When I read this message first thing I did was check the date, but deep down I knew it wasn't April yet. One of the top reasons why I hate using windows consoles is the dreaded "\" character. Each and every keyboard model I have has this key in a different place, sometimes one hard to reach. Every time I'm in doing a cd in windows I press 2-3 other keys while going for the backslash. That whole rating table over on the PHP wiki is just ridiculous. - type-ability: come on. If anything, it should get -1 there - typo-vulnerability: pretty big, but I think most problems will be escaping rather than typos anyway - number of chars: any sane person will agree that you can write "::" a lot faster than "\" - editor integration: not really, many editors will have trouble, including vim I eagerly await namespaces in PHP, but guys, if you don't have a good idea, I think copying is better than implementing a bad one. \Tudor --- ## #41382 — Lester Caine — 2008-10-26T14:23:30+00:00 URL: https://externals.io/message/41380#41382 · In reply to: #41380 Tudor Prodan wrote: > PHP has to be unique, using the double colon notation would be too > cliche, but if we're not respecting conventions, why not go with > something more exotic? I've always liked the o with the slash trough > it. The e with the horizontal colon is also pretty nice. The n with > the tilde over it, it so strongly says _n_amespace. > > When I read this message first thing I did was check the date, but > deep down I knew it wasn't April yet. > > One of the top reasons why I hate using windows consoles is the > dreaded "\" character. > > Each and every keyboard model I have has this key in a different > place, sometimes one hard to reach. Every time I'm in doing a cd in > windows I press 2-3 other keys while going for the backslash. > > That whole rating table over on the PHP wiki is just ridiculous. > - type-ability: come on. If anything, it should get -1 there > - typo-vulnerability: pretty big, but I think most problems will be > escaping rather than typos anyway > - number of chars: any sane person will agree that you can write > "::" a lot faster than "\" > - editor integration: not really, many editors will have trouble, including vim > > I eagerly await namespaces in PHP, but guys, if you don't have a good > idea, I think copying is better than implementing a bad one. Tudor - There is little point reiterating half of the facts. There are very good reasons why - for PHP - a simple solution was not working. MANY people were coming up with problems as to why the currently implemented 'solution' was only going to create a black hole at some point, and what ever was doing to be done was going to cause problems somewhere. The backslash is not ideal, but I think we all need to get behind it rather than complaining. The only other real alternative today is to shelve namespaces altogether for the next release rather than putting something in that is simply not practical to extend later? Given the polarised views a total solution that everybody could agree with was just not happening! -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #41430 — Tudor Prodan — 2008-10-27T09:33:11+00:00 URL: https://externals.io/message/41380#41430 · In reply to: #41382 Well, given how much PHP has copied from C (and I mean that in a good way), why not copy the sane, less-controversial namespace separator and behavior that we all know and love? \Tudor > Tudor Prodan wrote: > > […] > > Tudor - There is little point reiterating half of the facts. There are very > good reasons why - for PHP - a simple solution was not working. MANY people > were coming up with problems as to why the currently implemented 'solution' > was only going to create a black hole at some point, and what ever was doing > to be done was going to cause problems somewhere. > > The backslash is not ideal, but I think we all need to get behind it rather > than complaining. The only other real alternative today is to shelve > namespaces altogether for the next release rather than putting something in > that is simply not practical to extend later? > > Given the polarised views a total solution that everybody could agree with > was just not happening! > > -- > Lester Caine - G8HFL > ----------------------------- > Contact - http://lsces.co.uk/lsces/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk// > Firebird - http://www.firebirdsql.org/index.php --- ## #41431 — Alexey Zakhlestin — 2008-10-27T09:38:56+00:00 URL: https://externals.io/message/41380#41431 · In reply to: #41430 > Well, given how much PHP has copied from C (and I mean that in a good > way), why not copy the sane, less-controversial namespace separator > and behavior that we all know and love? because C is static, and PHP is dynamic it was already discussed — browse archives, please -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ --- ## #41433 — Vesselin Kenashkov — 2008-10-27T10:34:22+00:00 URL: https://externals.io/message/41380#41433 · In reply to: #41431 I want to express my happiness of finally having an agreement/solution for the namespaces. I have something like 70 000 LOC with namespaces (and a lot of static calls/class consts) so it will take some time to convert it to \ but I'm still very happy to have a solution. Like Karsten Dambekalns said in one of the threads it is more important to have ns support than the precise way it will be implemented/separator used, no matter that we have code written already - we will modify it. As a personal opinion - the backslash is fine for me because: - it is only one character - readable enough (something\another\thing) - no BC (like the proposed#hash#sign) - it will be somewhat familiar for the windows users (I'm not, but still is a +) I really hope that after testing the patch there will be no issues and this solution will get into the final version (and will put the end of the ns discussion). Big thanks to the people involved! -- Vesselin Kenashkov developer at www.webstudiobulgaria.com --- ## #41434 — Thomas Lee — 2008-10-27T11:02:25+00:00 URL: https://externals.io/message/41380#41434 · In reply to: #41382 Lester Caine wrote: > The backslash is not ideal, but I think we all need to get behind it > rather than complaining. The only other real alternative today is to > shelve namespaces altogether for the next release rather than putting > something in that is simply not practical to extend later? I'd prefer to see it shelved for another release with the aim of fixing whatever technical barriers made the syntax unworkable in the first place. I'm sure you'd have plenty of volunteers. My personal concern is that once this goes public, we (the end users) are stuck with that decision for the forseeable future. I think there's obviously enough unhappy campers here that this option should be at least considered. Not that I'm holding my breath or anything. Everybody seems to be getting awfully emotional about this ... Cheers, T --- ## #41435 — Arvids Godjuks — 2008-10-27T11:11:36+00:00 URL: https://externals.io/message/41380#41435 · In reply to: #41434 This was argued for months, there was tons of emails to read and backslash is best for most people. PHP is dynamic language - that makes some major restrictions, so you just can't apply something that is already in use easily. That's why :: was rejected in first place. That's why . was rejected, other separators had other issues. Backslash is easy to see, easy to type (most layouts have it without Shift or something else) and clearly says - I'm a namespace! So anyway - in any language you will find something that you would't like. You just live with that or chouse another language. That's all. 2008/10/27 Thomas Lee > Lester Caine wrote: > > > […] > I'd prefer to see it shelved for another release with the aim of fixing > whatever technical barriers made the syntax unworkable in the first place. > I'm sure you'd have plenty of volunteers. > > My personal concern is that once this goes public, we (the end users) are > stuck with that decision for the forseeable future. > > I think there's obviously enough unhappy campers here that this option > should be at least considered. Not that I'm holding my breath or anything. > > Everybody seems to be getting awfully emotional about this ... > > Cheers, > > T --- ## #41436 — Jevon Wright — 2008-10-27T11:21:53+00:00 URL: https://externals.io/message/41380#41436 · In reply to: #41435 So does that mean the new NS operator is actually \\ and not \ ? No developer is going to be relying on single \'s -- too likely to become an error in maintenence, and too inconsistent (see strings discussion). Jevon On Tue, Oct 28, 2008 at 12:11 AM, Arvids Godjuks wrote: > This was argued for months, there was tons of emails to read and backslash > is best for most people. PHP is dynamic language - that makes some major > restrictions, so you just can't apply something that is already in use > easily. That's why :: was rejected in first place. That's why . was > rejected, other separators had other issues. Backslash is easy to see, easy > to type (most layouts have it without Shift or something else) and clearly > says - I'm a namespace! > So anyway - in any language you will find something that you would't like. > You just live with that or chouse another language. That's all. > > 2008/10/27 Thomas Lee > > > […] > shelve > > […] > in > > […] > place. > > […] > anything. > > […] --- ## #41439 — Thomas Lee — 2008-10-27T11:38:07+00:00 URL: https://externals.io/message/41380#41439 · In reply to: #41435 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*. You're also right in that we can choose another language. I just wonder why you'd be so eager to encourage it. Anyway, my point is that there may be other options. Such as putting off a long-sought feature until it can be implemented properly. Cheers, T Arvids Godjuks wrote: > This was argued for months, there was tons of emails to read and backslash > is best for most people. PHP is dynamic language - that makes some major > restrictions, so you just can't apply something that is already in use > easily. That's why :: was rejected in first place. That's why . was > rejected, other separators had other issues. Backslash is easy to see, easy > to type (most layouts have it without Shift or something else) and clearly > says - I'm a namespace! > So anyway - in any language you will find something that you would't like. > You just live with that or chouse another language. That's all. > > 2008/10/27 Thomas Lee > > > > […] --- ## #41440 — Derick Rethans — 2008-10-27T11:47:00+00:00 URL: https://externals.io/message/41380#41440 · In reply to: #41439 > 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*. > > You're also right in that we can choose another language. I just > wonder why you'd be so eager to encourage it. > > Anyway, my point is that there may be other options. Such as putting > off a long-sought feature until it can be implemented properly. How would delyaing it help? We'd need to have the same discussion anyway. If we could have made :: work, we would have. Greg (and others) spend countless hours trying out different concepts, with different pros and cons -- you can find those on the wiki as RFCs. The only way how all issues could be solved was by picking a different namespace separator. There would have been anything that could have changed this without creating any sort of BC issues. From the possible namespace separators, \ was the best one as we could see. That's how it is, that's how it will be. Now get some coffee and quit bitching. Derick -- HEAD before 5_3!: http://tinyurl.com/6d2esb http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org --- ## #41441 — Steph Fox — 2008-10-27T12:06:09+00:00 URL: https://externals.io/message/41380#41441 · In reply to: #41439 Hi Thomas, > Anyway, my point is that there may be other options. Such as putting off a > long-sought feature until it can be implemented properly. OK, since you obviously didn't do any background reading before posting to this list, let me direct you to the history behind this decision once again: http://wiki.php.net/rfc/namespaceseparator. Let me also point out that this only covers the last few weeks; the namespace discussions on this very list, in-depth and otherwise, date back some 5 years. If you read everything linked from that RFC, you will discover that there are two ways to implement namespace support in PHP 'properly'. 1) We can offer support for classes only and throw a fatal error when a function is encountered in namespaced code 2) We can use a namespace separator other than :: There is of course always option 3... 3) We can drop the whole idea of namespace support because whatever is done will appear 'wrong' to /. readers Every other option leads to ambiguity in namespace syntax. That's not because we need more time to think things over so it can be 'implemented properly', it's just straight fact. - Steph --- ## #41442 — Alain Williams — 2008-10-27T12:16:02+00:00 URL: https://externals.io/message/41380#41442 · In reply to: #41439 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'. > 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 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'. > > > > […] > > 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 > > How would delyaing it help? I agree, delaying will not help (and namespaces are the most expected feature in PHP 5.3). > If we could have made :: work, we would have. Greg (and others) > spend countless hours trying out different concepts, with different pros > and cons -- you can find those on the wiki as RFCs. But what is the purpose of namespaces? To give developers their own separated space. And it is their responsibility to not use ambiguous names. PHP has not problem with class Foo::Bar and namespace Foo::Bar, but coding standards usually prohibits it. Developers are not stupid. I think there is no reason to PHP trying be smarter than them. (I know, this is kind of philosopher argument, but the same thinking works in C++ well). The only way how > all issues could be solved was by picking a different namespace > separator. There would have been anything that could have changed this > without creating any sort of BC issues. From the possible namespace > separators, \ was the best one as we could see. That's how it is, that's I will be glad for each separator, but :: is the best one :-)) David Grudl --- ## #41448 — Vesselin Kenashkov — 2008-10-27T12:52:40+00:00 URL: https://externals.io/message/41380#41448 · In reply to: #41443 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 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 > > > > > > […] > feel that > > […] > from the > > […] > '.' and ':' > > […] > family, eg: > > […] > do NOT > > […] > in a namespace. > > […] > is no great > > […] > $_NAMESPACEVARS['foo:.:bar'] > > […] > IT Lecturer. > > […] > http://www.phcomp.co.uk/contact.php > > […] > > -- > > > > -- Vesselin Kenashkov developer at www.webstudiobulgaria.com --- ## #41450 — Thomas Lee — 2008-10-27T13:02:11+00:00 URL: https://externals.io/message/41380#41450 · In reply to: #41441 Steph Fox wrote: > Hi Thomas, > > > > […] > > OK, since you obviously didn't do any background reading before > posting to this list, let me direct you to the history behind this > decision once again: http://wiki.php.net/rfc/namespaceseparator. Let > me also point out that this only covers the last few weeks; the > namespace discussions on this very list, in-depth and otherwise, date > back some 5 years. > Actually I've been following namespaces for a fair while, but the issue of :: being a problem wasn't really raised until a few weeks ago. So while I'm aware of namespaces being under discussion for a fair while, yesterday was the first I'd heard about a decision being made for the backslash being used as a namespace separator. Sounds like I'm not the only one. Hope it all works out, either way. Cheers, T --- ## #41451 — Thomas Lee — 2008-10-27T13:03:27+00:00 URL: https://externals.io/message/41380#41451 · In reply to: #41447 David Grudl wrote: > > But what is the purpose of namespaces? To give developers their own > separated space. And it is their responsibility to not use ambiguous > names. PHP has not problem with class Foo::Bar and namespace Foo::Bar, > but coding standards usually prohibits it. > +1 to that. Cheers, T --- ## #41452 — Steph Fox — 2008-10-27T13:26:29+00:00 URL: https://externals.io/message/41380#41452 · In reply to: #41450 Hi Thomas, > Actually I've been following namespaces for a fair while, but the issue of > :: being a problem wasn't really raised until a few weeks ago. So while > I'm aware of namespaces being under discussion for a fair while, yesterday > was the first I'd heard about a decision being made for the backslash > being used as a namespace separator. Sounds like I'm not the only one. OK, sorry if that seemed unfair. I should've aimed it at certain others really ;) You're correct, the :: issues were only fully understood when Greg took the time to investigate the options thoroughly. So you didn't miss a lot. Namespace *separator* discussions were long-winded and involved every Tom Dick and Harry turning up on internals@ with increasingly bizarre ideas, every time the subject arose over the last few years. That was when the real discussion of separator options took place. Lukas simply summarized the issues around the available options in his table during the irc discussion last Saturday, but the fact is he couldn't have really known the criteria - or the available symbols - without having those lengthy public discussions behind him. We couldn't have known his criteria and symbol set were correct without that history either; we'd have been stuck on 'why not :' forever. > Hope it all works out, either way. As do we all :) - Steph --- ## #41458 — Sean Coates — 2008-10-27T14:36:22+00:00 URL: https://externals.io/message/41380#41458 · In reply to: #41450 > Actually I've been following namespaces for a fair while, but the > issue of :: being a problem wasn't really raised until a few weeks > ago. I realize this isn't a terribly constructive comment as it doesn't solve any problems, but I hope it's constructive in the way that it actually causes people to do as Derick said and go get a coffee instead of whining about syntax... AGAIN. The issue of :: being a problem (causes ambiguity) was part of the ORIGINAL namespace discussion that took place 3 years ago. Some of us have been dealing with people complaining about this for 3 years (I blogged about ::: and \ in 2005), and I'm very happy we've finally come to a resolution. If the core developers chose another operator, then DIFFERENT people would be whining, so it's lose-lose. Now, sit back, relax, trust that the developers who chose this actually have half a clue, and stop crying wolf—all of you. S --- ## #41464 — Stanislav Malyshev — 2008-10-27T16:26:42+00:00 URL: https://externals.io/message/41380#41464 · In reply to: #41441 Hi! > If you read everything linked from that RFC, you will discover that > there are two ways to implement namespace support in PHP 'properly'. > > 1) We can offer support for classes only and throw a fatal error when a > function is encountered in namespaced code > 2) We can use a namespace separator other than :: These aren't the only ways. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #41467 — Steph Fox — 2008-10-27T16:52:49+00:00 URL: https://externals.io/message/41380#41467 · In reply to: #41464 > These aren't the only ways. OK. 4) Claim that there is no real problem in addressing ambiguous situations. - Steph --- ## #41469 — Stanislav Malyshev — 2008-10-27T17:08:35+00:00 URL: https://externals.io/message/41380#41469 · In reply to: #41467 Hi! > OK. > > 4) Claim that there is no real problem in addressing ambiguous situations. This is not what I meant, but there's obviously neither use nor interest in further discussing this topic as decision was already taken. I only wish people would not start rewriting history as other opinions or options didn't even exist so soon. I'm fine with making the choice, what I'm not fine with is presenting the thing as there was never any other options at all. We had plenty of options, maybe too many, we tried to choose the best, time will tell if we succeeded. Memory hole is not necessary for that. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #41470 — Steph Fox — 2008-10-27T17:24:07+00:00 URL: https://externals.io/message/41380#41470 · In reply to: #41469 > This is not what I meant, but there's obviously neither use nor interest > in further discussing this topic as decision was already taken. I only > wish people would not start rewriting history as other opinions or options > didn't even exist so soon. I'm fine with making the choice, what I'm not > fine with is presenting the thing as there was never any other options at > all. We had plenty of options, maybe too many, we tried to choose the > best, time will tell if we succeeded. Memory hole is not necessary for > that. My apologies. I was talking about what we were left with by the time we reached the point of needing a meeting. There were of course several attempts (recent and not so recent) to retain :: because this is what *everyone* would have preferred to do. I certainly didn't intend to leave the impression that this hadn't been investigated fully, or that there weren't several proposals of ways to get around the known problems. - Steph --- ## #41481 — Lester Caine — 2008-10-27T19:29:16+00:00 URL: https://externals.io/message/41380#41481 · In reply to: #41448 Vesselin Kenashkov wrote: > 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. I'm with you on that Vesselin. Will I use namespace - probably not, but I can see straight away blocks of code in projects I'm involved with that require functions at least in the namespace. SO they should be re-written? Probably, but one of the tidiest ways of handling even that is to wrap the legacy code in it's own namespace. If functions and constants were dropped simply to push an incomplete solution through, then it would cause a lot more trouble than the current flack. The result is not 'ideal' but it is perfectly functional and from what I've seen so far WILL work with legacy code. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php