# namespaces and alpha3 - Thread: https://externals.io/message/40997 - Original archive: https://news-web.php.net/php.internals/40997 - Started by Tony Bibbs on 2008-10-14T15:03:05+00:00 - Messages: 21 - 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 --- ## #40997 — Tony Bibbs — 2008-10-14T15:03:05+00:00 URL: https://externals.io/message/40997#40997 This is what I've be fearing. First slated for 5.0. Then 5.3. Now 6.0. It appears there's consensus to rip it out which, in my prior post, I was all for if people felt it meant getting it right. Apparently that is the case. I guess my main question is what keeps this from being pushed yet again once 6.0 drops? From the community standpoint we keep hearing "its coming, its coming" but here we are still waiting. Again, I'm fine with the decision but I think others share similar concerns and will want to hear a commitment (dare I say promise) to adding namespaces to 6.0. --Tony ----- Original Message ---- From: Stefan Walk To: internals@lists.php.net Sent: Tuesday, October 14, 2008 7:46:58 AM Subject: Re: [PHP-DEV] namespaces and alpha3 On Tuesday 14 October 2008 14:10:50 Steph Fox wrote: > I'm +1 on ripping out and leaving til 6.0. I don't think there is enough > time between now and the 5.3.0 code freeze to make major changes to the > language syntax. Major changes like ripping the feature that most people are looking forward to in 5.3 out? > Making -> do double duty and adding `E_STRICT` messages to > currently legal code really doesn't look like a good option to me, much > less during a point release and even less during the final moments of a > release cycle. That `E_STRICT` was proposed for 6, not for 5.3, and is not a requirement - and about "double duty", it's not really unintuitive to reference to "members" of classes the same way you reference to "members" of instances. > 'An announcement has been done on php.net' simply isn't a good enough > reason to screw up the language; we can write new announcements and even > explanations. And we already have *most* of a working implementation in > 6.0, so it's not like ripping it out of 5.3 means starting over from > scratch. I would love to see the public reaction to those "new announcements and explanations", so in a way it's a win-win situation for me. Regards, Stefan --- ## #40998 — Ron Rademaker — 2008-10-14T15:24:27+00:00 URL: https://externals.io/message/40997#40998 · In reply to: #40997 Tony Bibbs wrote: > This is what I've be fearing. First slated for 5.0. Then 5.3. Now 6.0. It appears there's consensus to rip it out which, in my prior post, I was all for if people felt it meant getting it right. Apparently that is the case. I guess my main question is what keeps this from being pushed yet again once 6.0 drops? From the community standpoint we keep hearing "its coming, its coming" but here we are still waiting. Again, I'm fine with the decision but I think others share similar concerns and will want to hear a commitment (dare I say promise) to adding namespaces to 6.0. > > --Tony > > > > ----- Original Message ---- > From: Stefan Walk > To: internals@lists.php.net > Sent: Tuesday, October 14, 2008 7:46:58 AM > Subject: Re: [PHP-DEV] namespaces and alpha3 > > On Tuesday 14 October 2008 14:10:50 Steph Fox wrote: > > > […] > > Major changes like ripping the feature that most people are looking forward to > in 5.3 out? > I'd really like to see namespace in 5.3. After reading most of the threads I'm still not real sure what the *real* problem is with the current implementation. It's down to stuff with constants and functions. IMO namespaces are very much an OO thing, meaning constants and functions should be in classes anyway. There's only a problem if you want there to be a problem. Foo::Bar::baz() is in class Bar in namespace Foo. Foo::Bar::BAZ is a constant in class Bar in namespace Foo. Ron --- ## #41000 — Stanislav Malyshev — 2008-10-14T17:34:42+00:00 URL: https://externals.io/message/40997#41000 · In reply to: #40997 Hi! > This is what I've be fearing. First slated for 5.0. Then 5.3. Now > 6.0. It appears there's consensus to rip it out which, in my prior > post, I was all for if people felt it meant getting it right. The thing is that there's nothing here that would improve with time. Pushing in to 6.0 is basically throwing it out forever, since there's nothing we could do in 6.0 that we can't do now, there's nothing that we could do "only if we had time", and only thing will happen towards the release of 6.0 is that we will repeat the whole story again. I don't see how anything will change in 6.0 from now except that it will happen in 2-3 years, so in the meantime PHP would miss a feature much needed, much advertised and much supported by the user base. We are at the point we just need to take decision. I understand the natural tendency of people to avoid taking complicated decisions by postponing the problem, but if you are not ready to take the responsibility, please do not try to put is as any kind of decision. It is not. If you don't know what to do with it, if you don't understand the feature, if you don't feel comfortable with deciding how it should be - don't say "let's throw it off", it is not a constructive approach. There's nothing that will change from now to 6.0 except that the people who worked a lot on this feature would be less ready to repeat the ordeal. So please do not allow inability to take decision and unwillingness to address the problem to deprive PHP users of much needed functionality. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #41001 — Steph Fox — 2008-10-14T17:46:54+00:00 URL: https://externals.io/message/40997#41001 · In reply to: #41000 Hi Stas, > The thing is that there's nothing here that would improve with time. Except the chance to test approaches that are currently only theories. > Pushing in to 6.0 is basically throwing it out forever, since there's > nothing we could do in 6.0 that we can't do now, there's nothing that we > could do "only if we had time", and only thing will happen towards the > release of 6.0 is that we will repeat the whole story again. Not so, most of it's there, agreed and tested. What there is, is already in PHP 6. I don't see > how anything will change in 6.0 from now except that it will happen in 2-3 > years, I would _hope_ it would happen from the moment 5.3 is out of the door, not at the last moment before the 6.0 release! > so in the meantime PHP would miss a feature much needed, much advertised > and much supported by the user base. > We are at the point we just need to take decision. I understand the > natural tendency of people to avoid taking complicated decisions by > postponing the problem, but if you are not ready to take the > responsibility, please do not try to put is as any kind of decision. This was one of the four options we were given. Just because you don't like it, doesn't mean there are now only three. > It is not. If you don't know what to do with it, if you don't understand > the feature, if you don't feel comfortable with deciding how it should > be - don't say "let's throw it off", it is not a constructive approach. > There's nothing that will change from now to 6.0 except that the people > who worked a lot on this feature would be less ready to repeat the ordeal. This is very negative, Stas. "Everybody wants it so let's push it out without testing". Do you really want a repeat of 5.0? > So please do not allow inability to take decision and unwillingness to > address the problem to deprive PHP users of much needed functionality. Please don't go emotional on us :) - Steph --- ## #41002 — Catalin Zamfir Alexandru | KIT Software CAZ — 2008-10-14T17:51:10+00:00 URL: https://externals.io/message/40997#41002 · In reply to: #41001 Guys, a recomandation (about namespaces): - if it's not tested enough, don't include it in the release. - if it's going to make a lot of confusion, don't include it in the release. - if neither of the two above won't stop it being included, and if there aren't 3 quarters (75%) of developers willing to accept namespaces, don't include it in the release. - in short, whatever feature that may cause more headaches or doesn't have any real support in the developer community should not be packed for a release. Those were my 2 cents ... Yours, Catalin Z. Alexandru ---------------------------- > -----Original Message----- > From: Steph Fox [mailto:steph@php.net] > Sent: Tuesday, October 14, 2008 8:47 PM > To: Stanislav Malyshev; internals@lists.php.net > Subject: Re: [PHP-DEV] namespaces and alpha3 > > Hi Stas, > > > […] > > Except the chance to test approaches that are currently only theories. > > > […] > we > > […] > > Not so, most of it's there, agreed and tested. What there is, is already > in > PHP 6. > > I don't see > > […] > 2-3 > > […] > > I would _hope_ it would happen from the moment 5.3 is out of the door, > not > at the last moment before the 6.0 release! > > > […] > advertised > > […] > > This was one of the four options we were given. Just because you don't > like > it, doesn't mean there are now only three. > > > […] > understand > > […] > approach. > > […] > people > > […] > ordeal. > > This is very negative, Stas. "Everybody wants it so let's push it out > without testing". Do you really want a repeat of 5.0? > > > […] > > Please don't go emotional on us :) > > - Steph --- ## #41004 — Stanislav Malyshev — 2008-10-14T18:05:50+00:00 URL: https://externals.io/message/40997#41004 · In reply to: #41001 Hi! > This is very negative, Stas. "Everybody wants it so let's push it out > without testing". Do you really want a repeat of 5.0? Nobody talks about "without testing", we are in alpha. But I'm talking about working on it, not pushing it under the carpet and hoping it somehow gets better there. I am working on it, so do other people, but chanting "let's remove it" is not working. If anything is "negative", this is. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #41006 — Steph Fox — 2008-10-14T18:21:23+00:00 URL: https://externals.io/message/40997#41006 · In reply to: #41004 Hi, > Nobody talks about "without testing", we are in alpha. But I'm talking > about working on it, not pushing it under the carpet and hoping it somehow > gets better there. I am working on it, so do other people, but chanting > "let's remove it" is not working. If anything is "negative", this is. We are in alpha indeed, and still looking at proposals, and still without consensus. The last thing I'd want is to see namespace support pushed under the carpet, but I'd rather see it at this stage of development as part of the PHP 6 development cycle (as originally planned) than in the 5.3 development cycle (where it probably doesn't belong anyway). It's become clear that there can't simply be a 'class-only' version in 5.3 without planning for potential extension of that in 6.0, and in fact that's the sticking point. We're trying to second-guess forward compatibility for something that doesn't yet exist in its final form. To me at least, that means namespace support is starting to look less and less feasible for 5.3 unless we can agree to never extend namespace support beyond classes. Which we don't. - Steph --- ## #41008 — Stanislav Malyshev — 2008-10-14T18:32:19+00:00 URL: https://externals.io/message/40997#41008 · In reply to: #41006 Hi! > We are in alpha indeed, and still looking at proposals, and still > without consensus. The last thing I'd want is to see namespace support > pushed under the carpet, but I'd rather see it at this stage of > development as part of the PHP 6 development cycle (as originally Why? What would happen then that can't happen now? > in its final form. To me at least, that means namespace support is > starting to look less and less feasible for 5.3 unless we can agree to > never extend namespace support beyond classes. Which we don't. We could agree on anything, if we only actually worked on agreeing, instead of working on it not happening. I am really surprised why you put so much effort into trying to undo the much needed feature. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #41010 — Steph Fox — 2008-10-14T19:01:14+00:00 URL: https://externals.io/message/40997#41010 · In reply to: #41008 Stas, > > […] > > Why? What would happen then that can't happen now? What would happen if we give the namespace implementation a chance to mature is that it can be delivered as a fully-fledged language element rather than a partially-fledged and potentially flawed one. > > […] > > We could agree on anything, if we only actually worked on agreeing, > instead of working on it not happening. I am really surprised why you put > so much effort into trying to undo the much needed feature. Not trying to undo it, just trying to prevent a horrible mistake being made under pressure. If I were trying to undo it, I'd be against namespace support in PHP 6 rather than suggesting its development belongs there! - Steph --- ## #41012 — Stanislav Malyshev — 2008-10-14T19:02:59+00:00 URL: https://externals.io/message/40997#41012 · In reply to: #41010 Hi! > What would happen if we give the namespace implementation a chance to > mature is that it can be delivered as a fully-fledged language element > rather than a partially-fledged and potentially flawed one. What do you mean by "chance to mature"? Only chance for it to mature is people actually starting using it and not another week of discussing separators on internals. And people can't start using it if it's not only not released but there are developers rooting for it to be removed. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #41013 — Steph Fox — 2008-10-14T19:12:37+00:00 URL: https://externals.io/message/40997#41013 · In reply to: #41012 > > […] > > What do you mean by "chance to mature"? Only chance for it to mature is > people actually starting using it and not another week of discussing > separators on internals. OK, bad choice of terminology. I really mean "a chance for the likelier problems to be ironed out". > And people can't start using it if it's not only not released but there > are developers rooting for it to be removed. Suddenly nobody uses CVS? I think if we were to ask explicitly for namespace testers on php.net once there's a full implementation we're all reasonably happy with, we'd find them. - Steph --- ## #41014 — Lukas Kahwe Smith — 2008-10-14T19:20:25+00:00 URL: https://externals.io/message/40997#41014 · In reply to: #41010 > > […] > > What would happen if we give the namespace implementation a chance > to mature is that it can be delivered as a fully-fledged language > element rather than a partially-fledged and potentially flawed one. Ok, lets slow down here for a second. We have 4 options. We know how things are without namespaces, we know how things are with the current implementation. This essentially leaves 2 choices that are untested for now. Both of these approaches have some uncleanness to them. If functions and constants get pushed to the global namespace while classes end up in the current namespace on include it can lead to some surprises. At the same time offering an ambiguous syntax to solve ambiguity when it occurs is also not beautiful. If we try out one of them in alpha3 and are unhappy I would not want an alpha4 to try out yet another one. But we will have the alpha3 either way at this point. So we could say lets try out the one that most people prefer for alpha3. If it sucks, we kick it out and move on. Then we can alternatively push it to PHP 6 or drop the idea all together. I know that Dmitry and Greg were both thinking over alternative approaches, which did not yet come to a conclusion. Most of that revolves around other separators between or around namespaces. So we can keep cooking that. Namespaces have turned out to be insanely complex. However it seems to me like most people that are voting are doing this on the basis that they feel that the problem itself is not yet understood by Stas/ Dmitry. I think they do understand the issue. That being said Greg also understands the issues well and disagrees with Stas, however I will leave it to him to decide on how to voice his concerns if at all. I am sure several other people on this list have followed the discussions close enough to be able to cast an educated vote. However if you do not understand the issues do not vote (I do of course not know who has been following the discussion or has not, so its up to each person to decide if they are in the loop enough to vote), unless you simply generally mistrust the approach taken to get to this point or the people involved. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #41016 — Steph Fox — 2008-10-14T19:41:20+00:00 URL: https://externals.io/message/40997#41016 · In reply to: #41014 Hi Lukas, > We have 4 options. We know how things are without namespaces, we know how > things are with the current implementation. This essentially leaves 2 > choices that are untested for now. True, true. > Both of these approaches have some uncleanness to them. If functions and > constants get pushed to the global namespace while classes end up in the > current namespace on include it can lead to some surprises. At the same > time offering an ambiguous syntax to solve ambiguity when it occurs is > also not beautiful. If we try out one of them in alpha3 and are unhappy I > would not want an alpha4 to try out yet another one. But we will have the > alpha3 either way at this point. So we could say lets try out the one > that most people prefer for alpha3. If it sucks, we kick it out and move > on. Good thinking - but we'll still see the same arguments even if most of us think it sucks. > Then we can alternatively push it to PHP 6 or drop the idea all together. Dropping the idea altogether's unlikely to be an option now. > I know that Dmitry and Greg were both thinking over alternative > approaches, which did not yet come to a conclusion. Most of that revolves > around other separators between or around namespaces. So we can keep > cooking that. Yeah... I never had a response to ::: so I guess that one's been dumped out of hand somewhere off-list, but darn I hate -> reuse with a passion! > Namespaces have turned out to be insanely complex. However it seems to me > like most people that are voting are doing this on the basis that they > feel that the problem itself is not yet understood by Stas/ Dmitry. Far from it. It's more that Stas/Dmitry (and Greg) have invested a lot of time and thought into the implementation and all three understandably want to see their work 'out there', whereas I'm far from alone in thinking it's just not ready to be 'out there' at this stage. - Steph --- ## #41020 — Robert Cummings — 2008-10-14T19:57:24+00:00 URL: https://externals.io/message/40997#41020 · In reply to: #41016 > > Yeah... I never had a response to ::: so I guess that one's been dumped out > of hand somewhere off-list, but darn I hate -> reuse with a passion! The use of ::: is far to simple. Nobody would want an elegant intuitive operator that uses 3 colons. 3 colons is just too much to pay for simplicity :::) I'm holding my +.0001 for something more complex... didn't someone mention £, €, and ¥ weren't getting enough attention? Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP --- ## #41024 — david.zuelke@bitextender.com — 2008-10-14T20:06:52+00:00 URL: https://externals.io/message/40997#41024 · In reply to: #41014 > > > > […] > > Both of these approaches have some uncleanness to them. If functions > and constants get pushed to the global namespace while classes end > up in the current namespace on include it can lead to some > surprises. At the same time offering an ambiguous syntax to solve > ambiguity when it occurs is also not beautiful. If we try out one of > them in alpha3 and are unhappy I would not want an alpha4 to try out > yet another one. But we will have the alpha3 either way at this > point. So we could say lets try out the one that most people prefer > for alpha3. If it sucks, we kick it out and move on. My fear is that once this is in a release (and even if it's just an alpha), the "public" pressure to keep it will be too big. > Then we can alternatively push it to PHP 6 or drop the idea all > together. I know that Dmitry and Greg were both thinking over > alternative approaches, which did not yet come to a conclusion. Most > of that revolves around other separators between or around > namespaces. So we can keep cooking that. I believe everyone here will agree that this decision is pretty crucial. And if Dmitry and Greg have alternative approaches in the pipeline that need further pondering, then we should wait until they either finalized their proposals or declared them infeasible themselves. Why the rush. I really don't understand it. Please, no half-arsed compromises. Or, as this little green dude once said, "do, or do not. there is no try." - David --- ## #41025 — Andi Gutmans — 2008-10-14T20:09:53+00:00 URL: https://externals.io/message/40997#41025 · In reply to: #41020 I don't think postponing this to another big release is going to do anyone any good. You will not see magical revelations because it's postponed by another year. Greg, Stas, Dmitry all three have deep understanding of the issues. In fact, I think we are closer to agreeing on a solution than it appears. I believe Dmitry is OK with Stas proposed solution + I think with a few more days of discussions with Greg we can nail something most feel OK with. Please note that the really important/urgent reasons for why namespaces are needed are resolved. Many of the discussions are around edge cases some of which are not that likely to affect developers on a daily basis. Stas' syntax suggestion for dealing with ambiguous situations will likely almost never be needed. So let's not make an elephant out of it. People who will actually start using this will find it beneficial (and I am sure pick-up will be faster in the OO realm than people here have noted). Btw, we are still in alpha. Historically a lot of these kind of issues have been resolved towards the end of the alpha cycle. That is OK. The beta/RC cycles are exactly intended to expose serious shortcomings in design with much broader community review. I can assure you two things though: a) namespaces are needed by many. b) We will never make everyone happy. Andi --- ## #41026 — Andi Gutmans — 2008-10-14T20:11:51+00:00 URL: https://externals.io/message/40997#41026 · In reply to: #41024 I think the three folks understand the sense of urgency to figure this out. They've done a lot of hard work over the past few months to get to this point. I think we're at the last 10 FT now and hopefully within 2-3 days they can come to an agreement. As I mentioned Dmitry is already OK with the current proposal and I think with some additional input from Greg we can figure this out. Andi --- ## #41028 — Steph Fox — 2008-10-14T20:45:36+00:00 URL: https://externals.io/message/40997#41028 · In reply to: #41025 Hi Andi, >I don't think postponing this to another big release is going to do anyone >any good. You will not see magical revelations because it's postponed by >another year. No, but we might see a broader agreement, and that would give more of a basis for user confidence in moving to namespace usage. > Greg, Stas, Dmitry all three have deep understanding of the issues. In > fact, I think we are closer to agreeing on a solution than it appears. I > believe Dmitry is OK with Stas proposed solution + I think with a few more > days of discussions with Greg we can nail something most feel OK with. I sincerely hope so. > Please note that the really important/urgent reasons for why namespaces > are needed are resolved. Many of the discussions are around edge cases > some of which are not that likely to affect developers on a daily basis. > Stas' syntax suggestion for dealing with ambiguous situations will likely > almost never be needed. So let's not make an elephant out of it. Was that pun intentional? :) >People who will actually start using this will find it beneficial (and I am >sure pick-up will be faster in the OO realm than people here have noted). That would rather depend on whether people like the implementation, methinks. > Btw, we are still in alpha. Historically a lot of these kind of issues > have been resolved towards the end of the alpha cycle. That is OK. The > beta/RC cycles are exactly intended to expose serious shortcomings in > design with much broader community review. > > I can assure you two things though: > a) namespaces are needed by many. > b) We will never make everyone happy. I concur. Just let's not get trapped into one solution while under pressure at alpha stage, and then be stuck with it forever if it turns out to be less than optimal. - Steph --- ## #41073 — Karsten Dambekalns — 2008-10-15T14:22:24+00:00 URL: https://externals.io/message/40997#41073 · In reply to: #41000 Hi. Stanislav Malyshev wrote: > > […] If 5.3 is not going to have namespaces, we will remove it's use from FLOW3 again and will not use them with PHP6 as well. That is because we can either include it now, or at the next major rewrite of our codebase (which is years away). > There's nothing that will change from now to 6.0 except that the people > who worked a lot on this feature would be less ready to repeat the > ordeal. I heartily second that. Regards, Karsten -- Karsten Dambekalns FLOW3 & TYPO3 Development TYPO3 Association --- ## #41074 — Karsten Dambekalns — 2008-10-15T14:22:33+00:00 URL: https://externals.io/message/40997#41074 · In reply to: #41010 Hi. Steph Fox wrote: > Not trying to undo it, just trying to prevent a horrible mistake being > made under pressure. What happened to "release when it is ready"? Who puts up that pressure? And why is there more pressure for 5.3 to be released than to release things that people have been hoping and waiting for for years? Regards, Karsten -- Karsten Dambekalns FLOW3 & TYPO3 Development TYPO3 Association --- ## #41118 — Stan Vassilev | FM — 2008-10-16T09:46:07+00:00 URL: https://externals.io/message/40997#41118 · In reply to: #41012 > Hi! > > > […] > > What do you mean by "chance to mature"? Only chance for it to mature is > people actually starting using it and not another week of discussing > separators on internals. And people can't start using it if it's not only > not released but there are developers rooting for it to be removed. There is a way to make both: have people use them, and not commit to BC or changes in 5.4 or a future release. Introduce E_EXPERIMENTAL as part of E_ALL. Make it the counterpart of E_STRICT. `E_STRICT` is reserved for deprecated features, and E_EXPERIMENTAL would complete this idea by letting us push experimental features such as namespaces (and any other extensions marked as "EXPERIMENTAL" in the manual) and have people play with them, so the core devs can get the feedback they need and improve or remove the feature in a future release. Have namespace related features throw E_EXPERIMENTAL warnings to people so they are aware this feature may not be present in a future release, or present but in another form. Regards, Stan Vassilev