# my last attempt at sanity with namespaces - Thread: https://externals.io/message/41090 - Original archive: https://news-web.php.net/php.internals/41090 - Started by Greg Beaver on 2008-10-15T20:35:11+00:00 - Messages: 77 - Page 1 of 4: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/41090.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 --- ## #41090 — Greg Beaver — 2008-10-15T20:35:11+00:00 URL: https://externals.io/message/41090#41090 Hi, http://wiki.php.net/rfc/namespaceissues Read it and discuss. Let's be clear people: the technical problems in namespaces are limited and solvable. The problems in the political environment surrounding them may not be. Wouldn't politics be a stupid-ass reason to remove namespaces? Greg --- ## #41091 — Guilherme Blanco — 2008-10-15T20:55:23+00:00 URL: https://externals.io/message/41090#41091 · In reply to: #41090 Hi, I spent almost all day long reading your emails about ns implementation (including one 100+ thread). There are many useless discussions to be honest, some of them almost going to personal side. I think this should be a simple thread of voting, instead of start another flame war here. For those that are considering only karma people, I help Pierre with windows website. Here are my votes: Namespace resolution issue: - explicit disambiguation with "use namespace blah::blah;" or "use class blah::blah;" __autoload calling order change: - I think a lot of people will have to adapt their implementation to not through Exception if class is not found (You can check that many tools do that). This will end up with always falling into your "autoload call escape fix" hint. So, I can live with it without troubles. You have a big one thumb up from me! Regards, > Hi, > > http://wiki.php.net/rfc/namespaceissues > > Read it and discuss. Let's be clear people: the technical problems in > namespaces are limited and solvable. The problems in the political > environment surrounding them may not be. Wouldn't politics be a > stupid-ass reason to remove namespaces? > > Greg > > -- > > > > -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9166-6902 MSN: guilhermeblanco@hotmail.com URL: http://blog.bisna.com Rio de Janeiro - RJ/Brazil --- ## #41093 — Kalle Sommer Nielsen — 2008-10-15T21:15:21+00:00 URL: https://externals.io/message/41090#41093 · In reply to: #41090 Hi Like Guilherme wrote, I've spend alot of my day reading the emails and trying to understand the namespace issues and after reading your proposal I understand the issues you're bringing up. So heres my votes: Conflict between namespaced functions and static class methods: I don't think it makes much sense to be able to make a class inside a namespace with the same name as another namespace, so my +1 here goes to option #4 (disallow mixing namespaces and classes with the same name). Resolving access to internal classes: I'm a +1 for changing the resolution order. Cheers, Kalle Sommer Nielsen --- ## #41098 — konference@kukulich.net — 2008-10-15T21:50:06+00:00 URL: https://externals.io/message/41090#41098 · In reply to: #41090 Hi, I have no karma but I read almost all threads about namespaces and I think I understand the issues. * Conflict between namespaced functions and static class methods: I prefer #1 but #3 is also good. * Resolving access to internal classes: +1 for the solution. Please don't remove namespaces from 5.3. We are really waiting for them. Regards --- ## #41099 — Nathan Rixham — 2008-10-15T21:52:04+00:00 URL: https://externals.io/message/41090#41099 · In reply to: #41093 Kalle Sommer Nielsen wrote: > Hi > > Like Guilherme wrote, I've spend alot of my day reading the emails and > trying to understand the namespace issues and after reading your > proposal I understand the issues you're bringing up. So heres my > votes: > > Conflict between namespaced functions and static class methods: > I don't think it makes much sense to be able to make a class inside a > namespace with the same name as another namespace, so my +1 here goes > to option #4 (disallow mixing namespaces and classes with the same > name). > > Resolving access to internal classes: > I'm a +1 for changing the resolution order. > > Cheers, > Kalle Sommer Nielsen out of the four options I'm: +1 to (disallow mixing namespaces and classes with the same name) +5 to changing the :: namespace operator personally I like period(.) IMO ::: is visually and legibly dire you can't namespace::class:::static_method() [or change the class::static() operator at all] as that would mean every reference to a static method in a class since eternity was using the wrong operator "use namespace"/"use class" syntax seems to bloat but certainly isn't disambiguous or use something completely mad like uri scheme's for namespaces! ns://one/step/two() ns://one/step::two() [the last comment should probably be disregarded] --- ## #41101 — Elizabeth M Smith — 2008-10-15T21:58:05+00:00 URL: https://externals.io/message/41090#41101 · In reply to: #41090 Greg Beaver wrote: > Hi, > > http://wiki.php.net/rfc/namespaceissues > > Read it and discuss. Let's be clear people: the technical problems in > namespaces are limited and solvable. The problems in the political > environment surrounding them may not be. Wouldn't politics be a > stupid-ass reason to remove namespaces? > > Greg Greg already knows how I feel - but for the rest of you +1 for #1 or #3 (greg has a patch for 3) - either way works great for my purposes +1 and of course make the resolution as greg mentioned on the rfc in the resolving access part (actually that was in stas's original original post and I didn't realize we were still arguing over it ;) Then I am ready to roll and will cease whining ;) Thanks for your work Greg, Elizabeth Smith --- ## #41102 — Andrei Zmievski — 2008-10-15T22:03:10+00:00 URL: https://externals.io/message/41090#41102 · In reply to: #41090 Thank you for the voice of sanity, Greg. I agree with your approach. -Andrei Greg Beaver wrote: > Hi, > > http://wiki.php.net/rfc/namespaceissues > > Read it and discuss. Let's be clear people: the technical problems in > namespaces are limited and solvable. The problems in the political > environment surrounding them may not be. Wouldn't politics be a > stupid-ass reason to remove namespaces? > > Greg --- ## #41103 — Janusz Lewandowski — 2008-10-15T22:59:56+00:00 URL: https://externals.io/message/41090#41103 · In reply to: #41090 Hi, Conflict between namespaced functions and static class methods: I think that #4 solution is the best one. If it will be accepted, it would be possible to extend namespaces in PHP6. For example, it would be possible to allow mixing namespaces and classes with same names, and disallow only mixing namespaced functions / static class methods. PHP 5.3 is too nearly for such a change, but in PHP6 you can make static class methods the same thing as functions and namespaced functions, with one additional feature for them (and maybe namespaced functions) - support for self::, static:: and parent::. This way, it will be also possible to add support for having both dynamic method and static method with the same name, but e.g. other parameters (like String::substring($string, 4, 2) and $string->substring(4, 2)). Resolving access to internal classes: I like your solution, it's much better than current resolution rules. Janusz Lewandowski --- ## #41106 — Steph Fox — 2008-10-16T02:29:11+00:00 URL: https://externals.io/message/41090#41106 · In reply to: #41090 Hi, > http://wiki.php.net/rfc/namespaceissues > > Read it and discuss. Let's be clear people: the technical problems in > namespaces are limited and solvable. The problems in the political > environment surrounding them may not be. Wouldn't politics be a > stupid-ass reason to remove namespaces? It sure would :) "Conflict between namespaced functions and static class methods" #3 is sheer brilliance IMHO. No BC issues for Karsten and friends, nice clear warnings on conflict and an easy way to fix them (I saw the draft patch), no performance hit any place that should matter, and above all - nobody else even thought of approaching the problem from that end in all this time, so kudos to you! Since I've been championing #2 for the last several weeks I obviously wouldn't object to that solution either, but I think #3 has far more elegance. "Resolving access to internal classes" I'll abstain on this one because I don't feel qualified to weigh the issues (ie I neither use nor write third-party dev tools). Thanks Greg! - Steph --- ## #41108 — Josh Davis — 2008-10-16T04:44:56+00:00 URL: https://externals.io/message/41090#41108 · In reply to: #41090 2008/10/15 Greg Beaver : > > Read it and discuss. Hello, First of all I'd like to thank Greg for his efforts to move the discussion in a positive direction. From a PHP user's point of view, it's comforting to see that this kind of discussion can still take place with a cool head and methodically. I have a question about #1 and #2: aren't they functionally the same? Based on current resolution rules (the ones used in the engine, not the ones currently documented in the manual) it is my understanding that there is only ever one namespace [resolution] operator and no namespace separator, because there is no hierarchy in namespaces. The "::" people use (myself included) to separate tokens in the namespace's name are for decoration only (a "visual aid", as per the old RFC) and they have no meaning. Therefore, users should be able to use any number of consecutive colons in a namespace name, before the namespace operator, just like we can use any number of consecutive underscores in class names and anywhere else. If the "::" contained in a namespace's name are separators, doesn't it mean that namespaces are de facto nested? Which brings me back to the current documentation, in which "new B::C" inside of namespace A would create an instance of class C from namespace A::B, as opposed to the current engine where it returns an instance of C from namespace B. I don't know if I'm reading too much into it, but as a user, the existence of "namespace separators" means to me that there multiple namespaces and that they are nested and it leads me to expect the old functionality (instance of A::B::C). Since that's not the case anymore, I wouldn't expect the number of consecutive ":" to be limited, making #1 and #2 the same. In fact, I wouldn't expect colons to be authorized in namespace names at all. Hoping I'm not opening a can of worms :) JD --- ## #41110 — Alexey Zakhlestin — 2008-10-16T06:25:01+00:00 URL: https://externals.io/message/41090#41110 · In reply to: #41090 > Hi, > > http://wiki.php.net/rfc/namespaceissues solution #3: +1 change of resolving order: +1 -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ --- ## #41114 — Derick Rethans — 2008-10-16T07:58:50+00:00 URL: https://externals.io/message/41090#41114 · In reply to: #41090 > http://wiki.php.net/rfc/namespaceissues > > Read it and discuss. Let's be clear people: the technical problems in > namespaces are limited and solvable. The problems in the political > environment surrounding them may not be. Wouldn't politics be a > stupid-ass reason to remove namespaces? In short: I'm for option #1 - and I would have to disagree with "con 1" there -- we shouldn't give a damn about what people did with unreleased code. As for the internal classes resolving, I am not too keen on slowing down internal classes access. Obviously, this is only going to be ab issue if you use namespaces though. The bad thing I find about it is that this resolving is done during runtime -- but I suppose that'd happen anyway because of autoload(). A bit on the reasoning against option #2: Option #2 introduces a new concept yet again. Namespaces are already a new concept, and trying to make it even more confusing wouldn't serve anybody. regards, Derick -- HEAD before 5_3!: http://tinyurl.com/6d2esb http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org --- ## #41115 — Vesselin Kenashkov — 2008-10-16T08:02:37+00:00 URL: https://externals.io/message/41090#41115 · In reply to: #41090 Thank you, Greg, for your efforts. My vote: +1 for 3) +1 for the change in __autolod() On Wed, Oct 15, 2008 at 11:35 PM, Greg Beaver wrote: > Hi, > > http://wiki.php.net/rfc/namespaceissues > > Read it and discuss. Let's be clear people: the technical problems in > namespaces are limited and solvable. The problems in the political > environment surrounding them may not be. Wouldn't politics be a > stupid-ass reason to remove namespaces? > > Greg > > -- > > > > -- Vesselin Kenashkov developer at www.webstudiobulgaria.com --- ## #41116 — Lars Strojny — 2008-10-16T09:11:51+00:00 URL: https://externals.io/message/41090#41116 · In reply to: #41090 Hello Greg, Am Mittwoch, den 15.10.2008, 15:35 -0500 schrieb Greg Beaver: [...] > http://wiki.php.net/rfc/namespaceissues > > Read it and discuss. Let's be clear people: the technical problems in > namespaces are limited and solvable. The problems in the political > environment surrounding them may not be. Wouldn't politics be a > stupid-ass reason to remove namespaces? Thanks for your efforts to fixing the remaining small issues with the current implementation. We wrote 50.000 LOC against 5.3 since half a year and I have to say the problems are minimal in the real world. But I understand the issues, especially the way how classnames are resolved are hard to guess. So +1 for your resolving proposal. The usage issue is not that easy for as I have a conflict of interests here: the lazy me votes for option 2 (no change for my code, ugly for those who use functions, which we don't do anyway), the one who weights whats best for PHP weights for option 3. So, the heck, let's do option 3, replacing "use Foo::Bar" with "use namespace Foo::Bar" is not that hard. Thanks for your solution! Lars -- Jabber: lars@strojny.net Weblog: http://usrportage.de --- ## #41117 — Karsten Dambekalns — 2008-10-16T09:22:09+00:00 URL: https://externals.io/message/41090#41117 · In reply to: #41090 Hi Greg, everyone. Greg Beaver wrote: > http://wiki.php.net/rfc/namespaceissues > > Read it and discuss. Let's be clear people: the technical problems in > namespaces are limited and solvable. The problems in the political > environment surrounding them may not be. Wouldn't politics be a > stupid-ass reason to remove namespaces? Oh, yeah, absolutely! "Conflict between namespaced functions and static class methods" I would prefer #1, but am equally happy with #3. Note: Rewriting what we currently have to make it work with changes in namespaces would be something we happily attack as soon as we know the direction. "Resolving access to internal classes" Great. And the autoload-for-internal classes issue would be no issue if (like we currently do) one explicitly refers to them like "::Exception" anyway. Regards, Karsten PS: We are still in Berlin at a TYPO3 core developer meeting, and I am happy to see this issue (almost) resolved. The same is true for the others here. Long live PHP! --- ## #41119 — Jochem Maas — 2008-10-16T09:52:42+00:00 URL: https://externals.io/message/41090#41119 · In reply to: #41090 Greg Beaver schreef: > Hi, > > http://wiki.php.net/rfc/namespaceissues > > Read it and discuss. Let's be clear people: the technical problems in > namespaces are limited and solvable. The problems in the political > environment surrounding them may not be. Wouldn't politics be a > stupid-ass reason to remove namespaces? well quite (although removal seems to me better than releasing without tackling the technical issues [those you documented in your latest RFC] ... but that's just me). so far as my +1 - I give my vote to Greg's preferred solution(s) (Greg get to vote with a +2 :-) ... I don't say this lightly, I've been convinced on-list and off- by detailed arguments and stacks of example code that Greg really has thought this through more than anyone else and what he offers is better than anything anybody else has brought to the table (regarding the issues highlighted in his last RFC) rgds, Jochem > > Greg --- ## #41120 — Richard Quadling — 2008-10-16T12:55:14+00:00 URL: https://externals.io/message/41090#41120 · In reply to: #41090 2008/10/15 Greg Beaver : > Hi, > > http://wiki.php.net/rfc/namespaceissues > > Read it and discuss. Let's be clear people: the technical problems in > namespaces are limited and solvable. The problems in the political > environment surrounding them may not be. Wouldn't politics be a > stupid-ass reason to remove namespaces? > > Greg With regard to accessing internal classes within a namespace, would using the namespace separator be enough? namespace blah; function __autoload($class) { include $class . '.php'; } $a = new Exception('hi'); // Internal $b = new :::Execption('lo'); // Namespaced It seems that it is up to me as the userland develop to explicitly identify namespaces vs classes (I like :::), so I would have though I'd need to deal with this when I want to call my namespaced class vs a built in class. Autoload would only get called if the correctly identified namespaced class wasn't already present. If I said use the built in class, then so be it. OOI, would __autoload get "blah:::Exception" or just "Exception" ? If the latter, how would I differentiate? -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" --- ## #41124 — Justin Carlson — 2008-10-16T14:37:22+00:00 URL: https://externals.io/message/41090#41124 · In reply to: #41120 +1 for option 3, http://wiki.php.net/rfc/namespaceissues Really don't want to see option 2. Richard Quadling wrote: > 2008/10/15 Greg Beaver : > > > […] --- ## #41126 — James Dempster — 2008-10-16T14:55:52+00:00 URL: https://externals.io/message/41090#41126 · In reply to: #41090 If I understand correctly I vote. +1 for Issue 1 option 1 +1 for Issue 2 > Hi, > > http://wiki.php.net/rfc/namespaceissues > > Read it and discuss. Let's be clear people: the technical problems in > namespaces are limited and solvable. The problems in the political > environment surrounding them may not be. Wouldn't politics be a > stupid-ass reason to remove namespaces? > > Greg --- ## #41127 — Christian Schneider — 2008-10-16T14:57:09+00:00 URL: https://externals.io/message/41090#41127 · In reply to: #41090 +1 for option 3 too (http://wiki.php.net/rfc/namespaceissues) - Chris --- ## #41130 — Ben Ramsey — 2008-10-16T15:17:59+00:00 URL: https://externals.io/message/41090#41130 · In reply to: #41090 > http://wiki.php.net/rfc/namespaceissues > > Read it and discuss. Let's be clear people: the technical problems in > namespaces are limited and solvable. The problems in the political > environment surrounding them may not be. Wouldn't politics be a > stupid-ass reason to remove namespaces? +1 for #3 -- Ben Ramsey http://benramsey.com/ --- ## #41132 — Ron Rademaker — 2008-10-16T15:24:39+00:00 URL: https://externals.io/message/41090#41132 · In reply to: #41090 Greg Beaver wrote: > Hi, > > http://wiki.php.net/rfc/namespaceissues > > Read it and discuss. Let's be clear people: the technical problems in > namespaces are limited and solvable. The problems in the political > environment surrounding them may not be. Wouldn't politics be a > stupid-ass reason to remove namespaces? > > Greg > > +1 on #3 --- ## #41134 — Stanislav Malyshev — 2008-10-16T15:27:34+00:00 URL: https://externals.io/message/41090#41134 · In reply to: #41090 Hi! > http://wiki.php.net/rfc/namespaceissues > > Read it and discuss. Let's be clear people: the technical problems in I think it would be better if we had limited number of variants. We have many people here with all kinds of opinions, but the thing is we need to choose ONE way and no more. So I'd propose to cut some options, otherwise I suspect some people would be discouraged by too many options, or we get equal distribution between many of them and will get nowhere. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #41135 — Stanislav Malyshev — 2008-10-16T15:37:05+00:00 URL: https://externals.io/message/41090#41135 · In reply to: #41090 Hi! > http://wiki.php.net/rfc/namespaceissues My opinion for the proposals: A. I'm ok with use namespace, but it is inferior to the -> proposal. While it allows explicit disambiguation, it does not allow to call both in the same file. I'm not sure it's too much of a problem but B. There's a huge problem with this proposal which you seem consistently to ignore despite all my attempts to explain it. Failed autoload on each call is BAD. Very bad. It is not cacheable, it leads to multiple disk accesses and it is absolutely undetectable to the PHP user without the use of special tools. So making all existing code contain this performance bomb unless you rewrite it is very bad. It's better to have this code fail and provide simple script to fix it in automatic fashion. The fix you propose - writing use's - is not enough because as you noted later inertia would make users not to use this code and thus have huge performance hit - which most of them even wouldn't know where it came from. I talked to many OO developers and most of them were OK with using :: on internal classes when using namespaces. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #41137 — Stanislav Malyshev — 2008-10-16T15:38:04+00:00 URL: https://externals.io/message/41090#41137 · In reply to: #41101 Hi! > +1 and of course make the resolution as greg mentioned on the rfc in the > resolving access part (actually that was in stas's original original > post and I didn't realize we were still arguing over it ;) NO, it wasn't in my proposal - my proposal was entirely different. My proposal does not include autoload performance bomb. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- Next page: https://externals.io/message/41090.md?page=2