# RFC: Dropping Namespace - Thread: https://externals.io/message/33694 - Original archive: https://news-web.php.net/php.internals/33694 - Started by Derick Rethans on 2007-12-04T22:16:12+00:00 - Messages: 115 - Page 1 of 5: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/33694.md?page=2 - 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 --- ## #33694 — Derick Rethans — 2007-12-04T22:16:12+00:00 URL: https://externals.io/message/33694#33694 Hello, following some discussions on the list (re. multiple namespaces in file) as well as a short discussion on IRC regarding not being able to do "use yeti::xml::DomDocument as DomDocument;" - I do not see any point in having namespaces at all. And my excuses for the somewhat longish mail... Some arguments: 1. As it is impossible to do "use XXX as NativeClass" we get to the point where we'd have to namespace new internal native classes otherwise we might introduce BC breaks. AFAIK, we've always said that PHP reserves the globals space for it's own use (see also: http://www.php.net/manual/en/userlandnaming.rules.php). In case we do add new classes (an example could be DateTimeSpan), they should of course follow the same format as already existing classes in the extension (DateTime, DateTimeZone). However introducing the new class DateTimeSpan might break people's code that do things like: feature versions of people would then show: Fatal error: Cannot use myNamespace::DateTimeZone as DomDocument because the name is already in use. It would be silly to require to have to do this: - Create a class PHP::Date::TimeSpan - In your scripts: use PHP::Date::TimeSpan But with the current implementation, this seems to be the only non-BC breaking solution. If we chose *not* to require this silly namespacing of internal classes, users instead have to do this: Basically prefixing the classnames... This you can already do just fine without namespaces. 2. You have to import every class yourself. You can currently not do: use myNamespace::* as *; // or similar syntax I understand why this is not implemented (runtime vs. compile time), but it is a bit of a pain in the ass if you use lots of classes from your own library f.e. 3. We keep bickering over using { } or not, multiple namespaces in a file or not... etc. I understand that people want more flexibility, but also we need a *simple* to explain implementation. With the current implementation I see the following problems here: - You can't stick multiple namespaces in one file - Unlike other constructs in PHP that mark executable blocks, namespaces don't use { }. - The "namespace" keyword at the start of a file is somewhat magic, because it can only appear as first element in your script. 4. What is wrong with simple prefixes in the first place? Both PEAR_*, Zend_*, ezc*, and ezp* are perfectly acceptable markers for different 'namespaces'. We could optionally create a registry on php.net for this to avoid conflicts. With all the above considerations, especially my first point, I still have not heard any good reason why namespaces in the current implementation are actually useful - or what particular case they solve... so I am wondering, are they really useful? I come now to the conclusion that they are not, and for myself (and most likely my work projects) I would have to decide not to go with namespaces, but instead stick with the 3 letter prefixing. Something that I have totally no problem with, as it is nice and easy. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org --- ## #33696 — Brian Moon — 2007-12-04T22:39:28+00:00 URL: https://externals.io/message/33694#33696 · In reply to: #33694 > With all the above considerations, especially my first point, I still have not > heard any good reason why namespaces in the current implementation are actually > useful - or what particular case they solve... so I am wondering, are they > really useful? I come now to the conclusion that they are not, and for myself > (and most likely my work projects) I would have to decide not to go with > namespaces, but instead stick with the 3 letter prefixing. Something that I > have totally no problem with, as it is nice and easy. I hate to, but I agree. If the only point is to make class naming pretty, it is kind of pointless. Give me namespaces that scope variables to a file and then we have something. Yeah, I still code the way PHP intended you to code, by templateing files together and not making gynormous classes to print out some simple HTML over and over. It would only be useful in that my company's code would not conflict with some 3rd party software we use. -- Brian Moon Senior Developer ------------------------------ http://dealnews.com/ It's good to be cheap =) --- ## #33697 — Steph Fox — 2007-12-04T22:41:44+00:00 URL: https://externals.io/message/33694#33697 · In reply to: #33694 Hi D, > extension (DateTime, DateTimeZone). However introducing the new class > DateTimeSpan might break people's code that do things like: > > use myNamespace::DateTimeZone as DateTimeZone; > ?> Typo? I guess you meant 'DateTimeSpan' to be in there somewhere... This is I think the biggest problem with the implementation, that new internal classes can still break userland code. The problem of single-file namespacing is only a problem because of the performance implications for those who bundle their includes, and it _should_ be possible to find a good way to resolve that. I don't really see a problem with the 'use only at the head of the file' thing (although I know others do); in fact I prefer it, because it makes for an easier upgrade path. Can I just ask one thing? If namespace support is once again pulled before it sees the light of a release, can we _please_ document exactly what the problems were, loud and clear, and put the document somewhere people are likely to see it? Thanks, - Steph --- ## #33699 — Gregory Beaver — 2007-12-04T23:36:50+00:00 URL: https://externals.io/message/33694#33699 · In reply to: #33694 Derick Rethans wrote: > With all the above considerations, especially my first point, I still have not > heard any good reason why namespaces in the current implementation are actually > useful - or what particular case they solve... so I am wondering, are they > really useful? I come now to the conclusion that they are not, and for myself > (and most likely my work projects) I would have to decide not to go with > namespaces, but instead stick with the 3 letter prefixing. Something that I > have totally no problem with, as it is nice and easy. I have to agree with all points except for the usefulness of "use" - the ability to re-alias classes is very nice. Incidentally, one argument - that you can't alias internal classes - is incorrect. Try this script: However, in the global scope (no namespace) it would fail. This is a bug that is easily fixed. use should allow re-aliasing of global classes, and I could provide a very easy fix. What if we simply kept the ability to alias classes via "use"? The best feature of the current namespace implementation is the ability to rename classes in a script. This way, you could use conflicting class names, as in this example: file1.php: file2.php: All the benefits of namespaces with none of the brackets or no brackets debate. Greg --- ## #33700 — Gregory Beaver — 2007-12-04T23:37:28+00:00 URL: https://externals.io/message/33694#33700 · In reply to: #33694 I used import in my last example instead of use, that was simply a typo, not trying to open a can of worms. Sorry, Greg --- ## #33701 — David Coallier — 2007-12-04T23:44:46+00:00 URL: https://externals.io/message/33694#33701 · In reply to: #33697 > Hi D, > > > […] > > Typo? I guess you meant 'DateTimeSpan' to be in there somewhere... > > This is I think the biggest problem with the implementation, that new > internal classes can still break userland code. The problem of single-file > namespacing is only a problem because of the performance implications for > those who bundle their includes, and it _should_ be possible to find a good > way to resolve that. I don't really see a problem with the 'use only at the > head of the file' thing (although I know others do); in fact I prefer it, > because it makes for an easier upgrade path. > > Can I just ask one thing? If namespace support is once again pulled before > it sees the light of a release, can we _please_ document exactly what the > problems were, loud and clear, and put the document somewhere people are > likely to see it? > > Thanks, > > - Steph > > > -- > > > > I never thought it would get back to the drawing board that way, but Derick, as I said on irc when we discussed about that, I agree with you. With the current implementation, the namespaces should be removed completely. Not only because it has missing features, but from the voice that comes out of the community, it seems that some features (important ones) (Point 2) and some PHP general concept (Point 3) are simply not what people want. I do not want to start a flamewar here, but again, the { } thread came up a few days ago and again, everyone who says that they get a performance gain by aggregating the files (Like compiled PHP files) are being either ignored or in some way insulted... Anyways, some people do not believe in the aggregation of the files, why's that ? I am not quite sure, well I have a few ideas but they are not appropriate for the mailing list, but the optimization technique that is aggregating the files work and I would really love to see it stay (At least the ability to decide if I want to aggregate them or not). And this is currently not possible with the implementation. Things like use * as * is something that is missing and a very important feature to my eyes as well. However, this kind of feature comes with education. If we allow people to use * as *, we have to explain them that the namespaces are not going to be coding for you. They might introduce the same conflicting errors as before when they had only classes. I want to make sure people understand that namespaces are not there to make one type less but as a great man once said, an additional structural element that is to be used correctly in order to work correctly. (You can give a nail to someone and he'll stick it in his eye instead of building a house... but if you show him how to use the nail correctly and with which other tools, he'll be able to build something solid... maybe...) From what I have experienced since the namespaces are in, my prefixing is still the way to go to make sure I can run all my nifty optimization scripts around and make a few "free" optimizations. This is a thread that will probably go deep in the sand in a few days (unless the community arises (which doesn't usually happen)) but for the records, if anyone has anything to say, it's still the time :) -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 --- ## #33702 — Stanislav Malyshev — 2007-12-05T01:13:21+00:00 URL: https://externals.io/message/33694#33702 · In reply to: #33694 > following some discussions on the list (re. multiple namespaces in file) > as well as a short discussion on IRC regarding not being able to do > "use yeti::xml::DomDocument as DomDocument;" - I do not see any point in having You mean like ability to override existing classes? I think it could be done but I don't see it as a good idea - it probably would lead to some weird programming mistakes. > 1. As it is impossible to do "use XXX as NativeClass" we get to the > point where we'd have to namespace new internal native classes > otherwise we might introduce BC breaks. AFAIK, we've always said that There's very easy solution to this, if it ever becomes a problem - using two-component names. > 2. You have to import every class yourself. You can currently not do: > > use myNamespace::* as *; // or similar syntax Right, you can't - but you can use two-component names, i.e. myNamespace::Name. > 3. We keep bickering over using { } or not, multiple namespaces in a > file or not... etc. I understand that people want more flexibility, > but also we need a *simple* to explain implementation. With the That's why not all flexibility gets in. > - You can't stick multiple namespaces in one file You are not supposed to unless you using it as performance solution, which is rather dubious practice anyway. > - Unlike other constructs in PHP that mark executable blocks, > namespaces don't use { }. That's because namespaces are not executable blocks. > - The "namespace" keyword at the start of a file is somewhat magic, > because it can only appear as first element in your script. Yes, it is somewhat magic, because it changes how names behave. If the whole thread is really reincarnation of the braces theme - I think you could just link to the archive, as I don't see any arguments here that weren't discussed to death three times. > 4. What is wrong with simple prefixes in the first place? Both PEAR_*, > Zend_*, ezc*, and ezp* are perfectly acceptable markers for different > 'namespaces'. We could optionally create a registry on php.net for > this to avoid conflicts. What is wrong is names like PEAR_DB_Data_Database_Module_Adapter_Implementation_Interface_Exception_Information_Collection_Element. When you write a code that uses such names, you really don't want to repeat all the thing every time. > useful - or what particular case they solve... so I am wondering, are they > really useful? I come now to the conclusion that they are not, and for myself Yes, they are. > (and most likely my work projects) I would have to decide not to go with > namespaces, but instead stick with the 3 letter prefixing. Something that I Well, the loss is all yours :) -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #33703 — Stanislav Malyshev — 2007-12-05T01:17:09+00:00 URL: https://externals.io/message/33694#33703 · In reply to: #33701 > up a few days ago and again, everyone who says that they get a > performance gain by aggregating the files (Like compiled PHP files) > are being either ignored or in some way insulted... Anyways, some That's the first time I hear asking somebody to help reproducing his benchmark is an insult. But how it has anything to do with removing namespaces? -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #33704 — Stanislav Malyshev — 2007-12-05T01:21:43+00:00 URL: https://externals.io/message/33694#33704 · In reply to: #33699 > However, in the global scope (no namespace) it would fail. This is a > bug that is easily fixed. use should allow re-aliasing of global > classes, and I could provide a very easy fix. This is not a bug - since there you work with test::xmlreader, which of course you can define. But in global space you'd work with existing name xmlreader, which would be redefined. And PHP never allowed redefining classes. > file1.php: > class DB {} > ?> > > file2.php: > import DB as Other_DB; > include 'file1.php'; > class DB extends Other_DB {} > ?> You mean 'use' should kill the old name? I don't think it's a good idea - we'd have to keep track of killed names, and since class can be named in a lot of ways - i.e. if you have name A::B::C::D you can alias any part of name, it would become messy. Why exactly you need to rename existing classes? -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #33707 — Steph Fox — 2007-12-05T01:33:47+00:00 URL: https://externals.io/message/33694#33707 · In reply to: #33704 > > […] > > This is not a bug - since there you work with test::xmlreader, which of > course you can define. But in global space you'd work with existing name > xmlreader, which would be redefined. And PHP never allowed redefining > classes. I'm truly glad you said that's not a bug, my world just started to make sense again. But Stas, consider (old dialect bc I need to update locally sorry): import nstest::test as whatever; This works in the global space, right? Now along comes, say, Pierre or Derick or Marcus with this class they just have to add to an existing (non-namespaced) core extension, and the obvious and perfect name for this class happens to be 'whatever'. I upgrade PHP and suddenly I start seeing Fatal error: Import name 'whatever' conflicts with defined class in ... Now sure, I can fix that. I can search and replace all my instances of 'whatever' in my code. How is that different from what we had before? Greg would say I should've namespaced this file, I know... but it's possible to use import (OK, 'use' now) in the global space, so how are you going to prevent people from doing that? - Steph --- ## #33709 — Stanislav Malyshev — 2007-12-05T01:52:13+00:00 URL: https://externals.io/message/33694#33709 · In reply to: #33707 > sense again. But Stas, consider (old dialect bc I need to update locally > sorry): > > import nstest::test as whatever; > > This works in the global space, right? Now along comes, say, Pierre or Right. > Derick or Marcus with this class they just have to add to an existing > (non-namespaced) core extension, and the obvious and perfect name for > this class happens to be 'whatever'. I upgrade PHP and suddenly I start > seeing Right again. The thing is this problem can not be solved. You can not both put all your classes into global namespace and expect them never to clash even when you name two of them by the same name. That's like you would talk in a language where all words would be "marklar" and expect me to understand you :) So what we can do is to avoid getting into such problem by using some rules. I'd propose these rules: 1. Namespace your libraries 2. Do not import the class name into global space, but only library name. Meaning, if your class is nstest::test, there's nothing wrong with saying just so, if you are concerned about clashes. That's not worse than you has nstest_test previously. But if you had PEAR::DB::Connection and PEAR::DB::Connection::Data and PEAR::DB::Connection::Exception and PEAR::DB::Query::Term and PEAR::DB::Query::Result, then you could do: use PEAR::DB as myDB; use PEAR::DB::Query as myQuery; and you'd have to do much less work: just myQuery::Term and myQuery::Result. > Now sure, I can fix that. I can search and replace all my instances of > 'whatever' in my code. How is that different from what we had before? If you insist on putting everything into globals space - it won't be. We just give you the option of not doing it. > Greg would say I should've namespaced this file, I know... but it's > possible to use import (OK, 'use' now) in the global space, so how are > you going to prevent people from doing that? I can't. I can only hope they would do it right, I can't force them to do it right :) -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #33710 — Steph Fox — 2007-12-05T01:56:58+00:00 URL: https://externals.io/message/33694#33710 · In reply to: #33709 > I can't. I can only hope they would do it right, I can't force them to do > it right :) I guess what I'm really asking is, 'is there any point in allowing import/use to be used in the global space?' I'm tired and etc, but I just can't visualize where it would be useful. Maybe one of the OO gang could put me straight here? - Steph > -- > Stanislav Malyshev, Zend Software Architect > stas@zend.com http://www.zend.com/ > (408)253-8829 MSN: stas@zend.com --- ## #33711 — Steph Fox — 2007-12-05T03:28:15+00:00 URL: https://externals.io/message/33694#33711 · In reply to: #33710 > I guess what I'm really asking is, 'is there any point in allowing > import/use to be used in the global space?' I'm tired and etc, but I just > can't visualize where it would be useful. And now I've finished reading old South Park episodes... OK, it's sinking in now. Because global import/use is something you only have to type once, whereas you'd have to add the namespace declaration, the relevant includes and any specific imports from the global namespace on a per-file basis (unless that last is a bug in my ageing PHP copy). Sorry, I'm slower than the average glacier tonight :( Even so... if you want your code to be safe from potential naming collisions you'd need to do all that stuff _anyway_, so what's the point in having a quick and dirty way to be unsafe? What am I missing here? Surely if people don't want to utilize namespacing in their own code they should just stick with fully qualified names? I'm asking a lot of questions because I'd _like_ this to work, I just don't see it as working if it's possible to break a namespaced application with third-party changes. To me that's the main reason for having namespace support in the first place, and without it, namespace support is just a way to prettify names. I'd like wildcard support too... and support for multiple namespaces per file (for bundling only)... but neither of those are complete deal-breakers in my eyes. Protection from naming collisions, is. - Steph --- ## #33712 — Larry Garfield — 2007-12-05T04:26:07+00:00 URL: https://externals.io/message/33694#33712 · In reply to: #33694 > 4. What is wrong with simple prefixes in the first place? Both PEAR_*, > Zend_*, ezc*, and ezp* are perfectly acceptable markers for different > 'namespaces'. We could optionally create a registry on php.net for > this to avoid conflicts. Although most people on the list seem to be coming at this problem assuming classes, I want to offer a counter-example that is all functions. In Drupal, our plugin architecture is based on function naming. When a given event "omg" occurs, something akin to the following frequently happens (a bit simplified): $hook = 'omg'; foreach ($modules_that_are_loaded as $module) { $function = $module .'_'. $hook; if (function_exists($function)) { $return[] = $function(); } } return $return; It's a very powerful mechanism, and quite flexible. The one thing it doesn't offer is, given a function name, determine what module and hook/event it is for. That's because we use PHP core coding standards, which say to use function_name for all functions. So given this function name: views_do_stuff() Is that the "do stuff" hook from the "views" module/plugin, or the "stuff" hook from the "views_do" module? Excellent question, and one that cannot be reliably solved. (There is a module called "views", but nothing is stopping anyone from writing a "views_do" module and declaring their own "stuff" hook.) That has actually come up recently as a problem, where we had to change the way a feature was implemented in order to avoid that problem of lack of introspection. (Ironically, it was when we were trying to implement lazy loading of a larger number of files to *improve* performance by reducing the amount of parsed-but-unused code we have.) We also are more and more coming across very_long_function_names since the function name must begin with the name of the module, which, if multi-word, can get quite long. When I saw the namespaces implementation, I realized that was a good solution to the problem. Instead of $module .'_'. $hook, use $module .'::'. $hook. That doesn't use namespaces as an alias or a shortener, but as, genuinely, a namespace. That's what's wrong with Long_Name_Prefixes. Aside from being a bitch to type or read, they don't contain as much introspective metadata as namespaces do. A registry on php.net to avoid collisions solves the problem for only one tiny sliver of use cases. If the problem with the current namespace implementation is that it doesn't go far enough, then the answer is not to drop it entirely but to finish it. Even if it's not useful in every use case, there are a lot of use cases where it is useful. To the other items raised: 1) "use MyDate as DateTime". I believe Greg pointed out the solution here. When PHP 5.5 is released and adds its own Whatever class, you just do the following: namespace me; use Whatever as LegacyWhatever; class Whatever{} It's a one-line change to keep your code working. I think that's acceptable, especially if we ensure that Whatever not existing in the global namespace (on 5.4) doesn't cause an error. As Stanislav noted, a complete solution is impossible. The Global namespace is a namespace, and you can't add things to a namespace and expect there to never be a collision within that namespace. Duh. :-) 2) No "use Foo::* as *". I can certainly see where that would be useful, but the lack of it does not mean that the entire namespace implementation must be thrown out. It still offers other benefits, even if it's not perfect (see above), and I don't see where adding * capabilities in a later version would cause a BC break syntactically, so worst case it's added later. 3) namespace keyword vs. {}. I've already said before that I prefer the {} syntax for consistency with other constructs. I am less bothered by the one-namespace-per-file rule than some, perhaps because I prefer to only parse the code I need rather than loading everything. (In my common use case, Drupal, that's a bigger performance win than vice versa.) I do agree that IF multiple namespaces are allowed in one file, {} makes a lot more syntactic sense than just a keyword. That said... is the keyword vs. {} issue worth deep sixing namespaces completely? If so, um, let's switch to {} (with or without multiple namespaces per file) and solve the problem? :-) For whatever the opinion of someone who writes PHP all day and not C is worth, there it is. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson --- ## #33713 — Robert Cummings — 2007-12-05T04:36:23+00:00 URL: https://externals.io/message/33694#33713 · In reply to: #33712 > > > > […] > > Although most people on the list seem to be coming at this problem assuming > classes, I want to offer a counter-example that is all functions. > > In Drupal, our plugin architecture is based on function naming. When a given > event "omg" occurs, something akin to the following frequently happens (a bit > simplified): > > $hook = 'omg'; > foreach ($modules_that_are_loaded as $module) { > $function = $module .'_'. $hook; > if (function_exists($function)) { > $return[] = $function(); > } > } > return $return; > > It's a very powerful mechanism, and quite flexible. The one thing it doesn't > offer is, given a function name, determine what module and hook/event it is > for. That's because we use PHP core coding standards, which say to use > function_name for all functions. So given this function name: > > views_do_stuff() > > Is that the "do stuff" hook from the "views" module/plugin, or the "stuff" > hook from the "views_do" module? Excellent question, and one that cannot be > reliably solved. (There is a module called "views", but nothing is stopping > anyone from writing a "views_do" module and declaring their own "stuff" > hook.) There ye have it! Namespace support is for people who didn't name their classes/functions properly. I'm not for or against it. Cheers, Rob. -- ........................................................... SwarmBuy.com - http://www.swarmbuy.com Leveraging the buying power of the masses! ........................................................... --- ## #33716 — Steph Fox — 2007-12-05T04:45:50+00:00 URL: https://externals.io/message/33694#33716 · In reply to: #33712 Hi Larry, > namespace me; > use Whatever as LegacyWhatever; > class Whatever{} I'd missed that in the ebb and flow. I guess the bug in my copy was fixed then, good. It still doesn't make sense to have global import though...? (I'm probably going to kick myself sooo hard for this in the morning...) - Steph --- ## #33714 — Sam Barrow — 2007-12-05T05:06:49+00:00 URL: https://externals.io/message/33694#33714 · In reply to: #33712 I think support for multiple namespaces in one file should definitely be used. As far as using curly braces vs using the namespace declaration, it doesn't really matter to me, however it is important that i be able to use the same namespace twice: namespace a { function function1() { return true ; } } // some other code namespace a { function function2() { return false ; } } --- ## #33715 — Sam Barrow — 2007-12-05T05:09:26+00:00 URL: https://externals.io/message/33694#33715 · In reply to: #33696 I think namespaces are very useful when it comes to PHP in large scale applications with hundreds of functions/classes. > > […] > > I hate to, but I agree. If the only point is to make class naming > pretty, it is kind of pointless. Give me namespaces that scope > variables to a file and then we have something. Yeah, I still code the > way PHP intended you to code, by templateing files together and not > making gynormous classes to print out some simple HTML over and over. > > It would only be useful in that my company's code would not conflict > with some 3rd party software we use. > > -- > > Brian Moon > Senior Developer > ------------------------------ > http://dealnews.com/ > It's good to be cheap =) --- ## #33717 — Nate Gordon — 2007-12-05T06:50:16+00:00 URL: https://externals.io/message/33694#33717 · In reply to: #33713 > > > > […] > > > $hook = 'omg'; > foreach ($modules_that_are_loaded as $module) > { > $function = $module .'__'. $hook; > if (function_exists($function)) > { > $return[] = $function(); > } > } > return $return; > > ?> > > There ye have it! > > > list( $module, $hook ) = explode( '__', $function ); > > ?> > > Namespace support is for people who didn't name their classes/functions > properly. I'm not for or against it. To paint namespaces with such a broad brush isn't terribly fair. I see other languages such as Java/Perl/C++ using packages/namespace foo in much the same way I see some people wanting to use it here. As a way to shorten really long class names while reducing conflicts. This isn't a new feature to programming in general. The problem I see going on here is the desire by some to make it do everything _and_ wash the dishes. While noble and probably well intentioned, does feature X really serve the greater good? It can't solve every problem and still be something that people want to use. Php already has a ton of stuff in the global namespace, so I don't know that namespaces can fix collisions/BC overnight. Once namespaces have a foothold then people can start looking at how to migrate all the stuff in the global namespace outwards without causing major problems. While PHP::Time::DateSpan might seem silly to some, it seems fairly normal in the other languages I program in (Java, Perl). I would also be perfectly fine with php core laying claim to Time::*. Its just a fact of life that the global namespace has a limited amout of real estate and people can't just go snatching up all the good names just because they were there first. I vote for starting small. Add namespaces. Allow people to do basic use statements. I would even be in favor of multiple namespaces per file, but would prefer if they were wrapped in {} (it seems more consistent and easier to mentally parse) otherwise I don't care. From reading emails today I hope this might be some sort of middle ground that might prevent completely tossing out this feature. Having said all of that, you can't stop bad programmers from doing at least something wrong. Especially not in a language like PHP where you are given so much freedom to do what you want. -- -Nathan Gordon If the database server goes down and there is no code to hear it, does it really go down? :wq I'd like wildcard support too... and support for multiple namespaces > per file (for bundling only)... but neither of those are complete > deal-breakers in my eyes. Protection from naming collisions, is. FULLACK, the good news is that i accidently mailed Gregory off-list yesterday and he seems to have a good solution. --- ## #33719 — Derick Rethans — 2007-12-05T08:39:39+00:00 URL: https://externals.io/message/33694#33719 · In reply to: #33699 > However, in the global scope (no namespace) it would fail. This is a > bug that is easily fixed. use should allow re-aliasing of global > classes, and I could provide a very easy fix. No, use should not allow this. Take the following example: loadXML('blah'); $s = simplexml_import_dom($dom); echo $s->book[0]->title; // blah ?> Besides this being a *big* WTF factor (why is my internal class suddendly doing something else?) simplexml will horrible fail in this case. Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org --- ## #33720 — Robert Lemke — 2007-12-05T08:52:29+00:00 URL: https://externals.io/message/33694#33720 · In reply to: #33694 Hi Derick, I also agree with your arguments - beautifying class names is not reason enough for introducing namespaces. On 04.12.2007 at 23:16 Derick Rethans wrote: > 4. What is wrong with simple prefixes in the first place? Both PEAR_*, > Zend_*, ezc*, and ezp* are perfectly acceptable markers for > different > 'namespaces'. We could optionally create a registry on php.net for > this to avoid conflicts. While experimenting with namespaces to use with the next major version of TYPO3, I realized that always using a full class name such as "T3_MyPackage_MySubPackage_Controller_DefaultController" has many advantages. Autoloading becomes a lot easier and if the filename equals the class name (ie. the full name, not only "DefaultController.php") you are never in doubt where a file belongs to or comes from. Therefore we in the TYPO3 project currently tend to not using namespaces even if PHP6 had support for them. robert -- WE NEED UNICODE! http://typo3.org/gimmefive http://buzz.typo3.org/people/robert-lemke/ --- ## #33721 — Derick Rethans — 2007-12-05T08:53:34+00:00 URL: https://externals.io/message/33694#33721 · In reply to: #33702 > > […] > > You mean like ability to override existing classes? I think it could be done > but I don't see it as a good idea - it probably would lead to some weird > programming mistakes. Of course, I think allowwing this is a really bad idea - which brings me to the main point of this argument: > > […] > > There's very easy solution to this, if it ever becomes a problem - using > two-component names. And that is exactly what I think we should not do. PHP reserves the global scope. period. That means that (core)extensions should not have to deal with all sorts of namespace clue or other tricks just because some people like a "misguided" implementation of namespaces. The idea of namespaces is to prevent collisions in USER land code, not turning internal PHP classes into a pile of goo. > > […] > > That's why not all flexibility gets in. > > > […] > > You are not supposed to unless you using it as performance solution, which is > rather dubious practice anyway. You're not supposed to put a count($array) inside your for loop either. I don't quite understand why allowing multiple namespaces is such a big issue, however - it won't solve the naming collision issue. > > […] > > That's because namespaces are not executable blocks. Neither are classes. > > […] > > What is wrong is names like > PEAR_DB_Data_Database_Module_Adapter_Implementation_Interface_Exception_Information_Collection_Element. > When you write a code that uses such names, you really don't want to repeat > all the thing every time. No, but, do you really need to have such long names? And besides that, you *have* to keep repeating them in every file you'd want to use them - which means you actually have to type *more* in some places. So this argument is kind of lame. > > […] > > Yes, they are. Just saying "Yes, they are" is not a very good argument - actually, it's not an argument at all. > > […] > > Well, the loss is all yours :) Actually, it's exactly the opposite, as I avoid naming colissions (point 1), I don't need to import every class I want to use (point 2), and can group all my classes together in one file (point 3). regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org --- ## #33723 — Derick Rethans — 2007-12-05T08:55:40+00:00 URL: https://externals.io/message/33694#33723 · In reply to: #33712 > 1) "use MyDate as DateTime". I believe Greg pointed out the solution here. > When PHP 5.5 is released and adds its own Whatever class, you just do the > following: > > namespace me; > use Whatever as LegacyWhatever; > class Whatever{} > > It's a one-line change to keep your code working. I think that's acceptable, It's not acceptable, as you're breaking BC. > For whatever the opinion of someone who writes PHP all day and not C > is worth, there it is. What makes you think I am different? regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org --- ## #33724 — Dmitry Stogov — 2007-12-05T09:25:20+00:00 URL: https://externals.io/message/33694#33724 · In reply to: #33719 I don't understand what are you going to demonstrate with this example. Did you try to run it? It produces error as expected. DOMDocument() in your example is a user-space class that is not related to internal ext/dom class. If you like to use internal class that is overriden in namespace you can use ::DomDocument instead. The "use DomDocument as test;" is useless from my point of view. You always may override internal classes in namespaces. Thanks. Dmitry. Derick Rethans wrote: > > > > […] > > No, use should not allow this. Take the following example: > > namespace blah; > use DomDocument as test; > > class DOMDocument { } > > $dom = new DOMDocument; // > $dom->loadXML('blah'); > $s = simplexml_import_dom($dom); > > echo $s->book[0]->title; // blah > ?> > > Besides this being a *big* WTF factor (why is my internal class > suddendly doing something else?) simplexml will horrible fail in this > case. > > Derick --- Next page: https://externals.io/message/33694.md?page=2