# namespaces and alpha3 - Thread: https://externals.io/message/40906 - Original archive: https://news-web.php.net/php.internals/40906 - Started by Lukas Kahwe Smith on 2008-10-10T05:03:19+00:00 - Messages: 39 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/40906.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 --- ## #40906 — Lukas Kahwe Smith — 2008-10-10T05:03:19+00:00 URL: https://externals.io/message/40906#40906 Hi All, There was an offline exchange, which generated a lot of good ideas, but that failed to find agreement for one final proposal among the participants. I had hoped that the results would have been mailed to this list yesterday. Since I am going on yet another frisbee trip in about an hour, I am putting on the thumb screws with this post. Stas might update his proposal and Dmitry has a proposal that makes some more modifications to be able to handle functions/constants in namespaces without ambiguities. I will leave it to them to send their proposals to the list. At this point I guess we have the choice between: 1) rip them out 2) status quo 3) Stas proposal 4) Dmitrys proposal Again I hope that Stas/Dmitry will give us an insight about their proposals, though Stas proposal might or might not see any changes. In my dream world you all would come to an agreement, finish up the patches by Monday so that we could release alpha3 next Thursday. Since that is not going to happen we will see alpha3 on the 21st I guess. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #40907 — Kalle Sommer Nielsen — 2008-10-10T05:11:29+00:00 URL: https://externals.io/message/40906#40907 · In reply to: #40906 2008/10/10 Lukas Kahwe Smith : > Hi All, > > There was an offline exchange, which generated a lot of good ideas, but that > failed to find agreement for one final proposal among the participants. I > had hoped that the results would have been mailed to this list yesterday. > Since I am going on yet another frisbee trip in about an hour, I am putting > on the thumb screws with this post. Stas might update his proposal and > Dmitry has a proposal that makes some more modifications to be able to > handle functions/constants in namespaces without ambiguities. I will leave > it to them to send their proposals to the list. > > At this point I guess we have the choice between: > > 1) rip them out > 2) status quo > 3) Stas proposal If stats proposal is the one where functions and constants are removed from namespaces, then Im +1 for that proposal. > 4) Dmitrys proposal > > Again I hope that Stas/Dmitry will give us an insight about their proposals, > though Stas proposal might or might not see any changes. > > In my dream world you all would come to an agreement, finish up the patches > by Monday so that we could release alpha3 next Thursday. Since that is not > going to happen we will see alpha3 on the 21st I guess. > > regards, > Lukas Kahwe Smith > mls@pooteeweet.org > > > > > -- > > > > -- Kalle Sommer Nielsen --- ## #40928 — Geoffrey Sneddon — 2008-10-10T16:56:11+00:00 URL: https://externals.io/message/40906#40928 · In reply to: #40906 > 1) rip them out I'm +1 on this. We simply don't have consensus, and I don't see anyway we can have consensus by the time 5.3 has to be frozen. Once namespaces are in, we're gonna have to stick with whatever we choose, unless we totally break BC. -- Geoffrey Sneddon 3) Stas proposal I have two proposals, actually. 1. Leave functions (and constant) alone, i.e. namespace would ignore that. 1.1 Option: if you define function inside namespace, compiler could give an error (I don't like this option, but I mention it for the sake of completeness). 2. Leave functions/constants as they are now, and add the following syntax: Class::Name->method() for calling static methods (and referring to class constants), so that there would be a way to disambiguate calls in (rare, IMHO) situations where ambiguity may arise. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #40947 — Lars Strojny — 2008-10-13T07:10:28+00:00 URL: https://externals.io/message/40906#40947 · In reply to: #40906 Hi Lukas, Am Freitag, den 10.10.2008, 07:03 +0200 schrieb Lukas Kahwe Smith: [...] > 3) Stas proposal +1 here. cu, Lars -- Jabber: lars@strojny.net Weblog: http://usrportage.de --- ## #40949 — Stefan Walk — 2008-10-13T09:37:02+00:00 URL: https://externals.io/message/40906#40949 · In reply to: #40929 On Friday 10 October 2008 19:02:25 Stanislav Malyshev wrote: > Hi! > > > […] > > I have two proposals, actually. [snip] > 2. Leave functions/constants as they are now, and add the following syntax: > Class::Name->method() > for calling static methods (and referring to class constants), so that > there would be a way to disambiguate calls in (rare, IMHO) situations > where ambiguity may arise. This certainly seems like the best proposal. Regards, Stefan --- ## #40953 — Dmitry Stogov — 2008-10-13T18:19:07+00:00 URL: https://externals.io/message/40906#40953 · In reply to: #40929 Stanislav Malyshev wrote: > 2. Leave functions/constants as they are now, and add the following syntax: > Class::Name->method() > for calling static methods (and referring to class constants), so that > there would be a way to disambiguate calls in (rare, IMHO) situations > where ambiguity may arise. I would be glad with this one. Thanks. Dmitry. --- ## #40968 — Lukas Kahwe Smith — 2008-10-14T07:31:39+00:00 URL: https://externals.io/message/40906#40968 · In reply to: #40929 It should be noted that this proposal builds on Stas previous proposal after Zendcon > 1. Allow braces for namespaces. So, the syntax for namespaces will be: > a) namespace foo; > should be first (non-comment) statement in the file, namespace > extends to the end of the file or next namespace declaration. > b) namespace foo {} > can appear anywhere on the top scope (can not be nested). > Mixing both syntaxes in one file is not possible. The semantics of > both syntaxes will be identical. > > 2. Simplify resolution order for classes in the namespace: > unqualified names are resolved this way: > a) check "use" list if the name was defined at "use", follow that > resolution > b) if not, the name resolves to namespace::name > Consequence of this will be that for using internal class inside > namespace one would need to refer to it either as ::Foo or do > use ::Foo prior to its usage. The original 3rd point from the proposal now has the following two optional solutions (the first one being the originally proposed approach): > I have two proposals, actually. > > 1. Leave functions (and constant) alone, i.e. namespace would ignore > that. > 1.1 Option: if you define function inside namespace, compiler could > give an error (I don't like this option, but I mention it for the > sake of completeness). I am -1 on this one. > 2. Leave functions/constants as they are now, and add the following > syntax: > Class::Name->method() > for calling static methods (and referring to class constants), so > that there would be a way to disambiguate calls in (rare, IMHO) > situations where ambiguity may arise. I am +0.5(*) on this one. I dont like the fact that this means that code needs to be migrated before being unambiguous, so I preferred the idea of having a different separator between namespaces and its members, but this way there is at least a solution available. (*) There is a condition under which I would be +1 for the syntax. If in PHP6 we can make the old syntax (A::foo() and A::FOO) raise an `E_STRICT` (I dont think we ever want to remove it, so `E_DEPRECATED` would not be the right choice), when its being used to reference class members instead of namespace elements. If I understand the namespace resolution rules properly, we check namespaces first before checking for a class with the same name. So with the `E_STRICT` in place, developers could protect themselves perfectly from accidental ambiguities (if they were to ever introduce a namespace with the same name as a class with a constant or static method that is referenced using the double colon) and effectively migrate to the new syntax (which I think is nicer anyways, than the original syntax). --- Barring any new major findings I ask everybody to cast their vote by Thursday evening PST. Since Dmitry was not happy with his proposal we are left with: 1) Rip them out 2) Keep as is 3) Stas proposal with functions/constants ignored 4) Stas proposal with "->" optionally allowed to resolve ambiguities If we have a decision by Thursday evening we could hopefully do an alpha3 by Thursday the following week, although I would want any namespace to be documented before (or closely around) the release of alpha3. Stas said that he would be willing to update the README in a timely manner after finishing a patch, in case we go for 3) or 4). I hope we can also find the time to transfer any changes to docbook quickly after this. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #40971 — James Dempster — 2008-10-14T08:12:07+00:00 URL: https://externals.io/message/40906#40971 · In reply to: #40928 On Fri, Oct 10, 2008 at 5:56 PM, Geoffrey Sneddon wrote: > > > > 1) rip them out > > […] > > I'm +1 on this. We simply don't have consensus, and I don't see anyway we > can have consensus by the time 5.3 has to be frozen. Once namespaces are in, > we're gonna have to stick with whatever we choose, unless we totally break > BC. > > > -- > Geoffrey Sneddon > I'd agree with this, leave something with such a big impact to version 6. At least it gives time to get it right. --- ## #40973 — technique@dev-solutions.fr — 2008-10-14T08:41:52+00:00 URL: https://externals.io/message/40906#40973 · In reply to: #40971 Le mardi 14 octobre 2008 à 09:12 +0100, James Dempster a écrit : > On Fri, Oct 10, 2008 at 5:56 PM, Geoffrey Sneddon > […] > > > […] > > > I'd agree with this, leave something with such a big impact to version 6. At > least it gives time to get it right. I don't agree to this, many of us are waiting for namespaces and have starting to impact some code in prevision. Don't forget that an annoucement has been done on php.net and a final release of 5.3 without namespaces could be interpreded as a regression. Stephane --- ## #40975 — Steph Fox — 2008-10-14T12:10:50+00:00 URL: https://externals.io/message/40906#40975 · In reply to: #40973 > > […] > > I don't agree to this, many of us are waiting for namespaces and have > starting to impact some code in prevision. > > Don't forget that an annoucement has been done on php.net and a final > release of 5.3 without namespaces could be interpreded as a regression. 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. 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. Leaving as-is, we already know is problematic. There's no consensus to pull support for functions/constants, which would make it less problematic. '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. - Steph --- ## #40977 — Jochem Maas — 2008-10-14T12:20:46+00:00 URL: https://externals.io/message/40906#40977 · In reply to: #40975 Steph Fox schreef: > > […] +1 ... I concur with Steph's opinion > > […] > > 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. 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. Leaving as-is, we already know is problematic. > There's no consensus to pull support for functions/constants, which > would make it less problematic. > > '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. > > - Steph --- ## #40978 — Lukas Kahwe Smith — 2008-10-14T12:25:35+00:00 URL: https://externals.io/message/40906#40978 · In reply to: #40975 > > 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. 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. Leaving as-is, we > already know is problematic. There's no consensus to pull support > for functions/constants, which would make it less problematic. Just for the record, I was suggesting to add the `E_STRICT` in PHP6, not in PHP 5.3. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #40979 — Steph Fox — 2008-10-14T12:33:54+00:00 URL: https://externals.io/message/40906#40979 · In reply to: #40978 Hi Lukas, > Just for the record, I was suggesting to add the `E_STRICT` in PHP6, not in > PHP 5.3. I'd missed that, but it doesn't make a whole lot of difference IMHO. The reuse of an existing symbol is going to bring problems, and if we do it now we'll be blocking the possibility of a better resolution. - Steph --- ## #40981 — Steph Fox — 2008-10-14T12:39:42+00:00 URL: https://externals.io/message/40906#40981 > Many people have starting working on top level application using > namespaces, so there will a very bad buzz over the php community if > namespaces are ripped out... People working with a development branch take their own chances. We keep BC for released code, not for dev code. - Steph --- ## #40982 — Stefan Walk — 2008-10-14T12:46:58+00:00 URL: https://externals.io/message/40906#40982 · In reply to: #40975 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 --- ## #40983 — James Dempster — 2008-10-14T12:57:26+00:00 URL: https://externals.io/message/40906#40983 On Tue, Oct 14, 2008 at 1:34 PM, Jean-philippe Serafin < jean-philippe.serafin@dev-solutions.fr> wrote: > Many people have starting working on top level application using > namespaces, so there will a very bad buzz over the php community if > namespaces are ripped out... There code should work fine in PHP 6 without any changes from what I understand. Taking it out of 5.3 gives extra time and puts any possible BC breakages to a major version of PHP. --- ## #40984 — Vesselin Kenashkov — 2008-10-14T12:58:11+00:00 URL: https://externals.io/message/40906#40984 · In reply to: #40968 I'm very happy with the current implementation of the namespaces, so my vote would be to keep it as it is. Otherwise my "fallback vote" would be for the '->' operator. I do find the namespaces very useful and I would like to see them in whatever shape in 5.3. > 1) Rip them out > 2) Keep as is > 3) Stas proposal with functions/constants ignored > 4) Stas proposal with "->" optionally allowed to resolve ambiguities > > If we have a decision by Thursday evening we could hopefully do an alpha3 > by Thursday the following week, although I would want any namespace to be > documented before (or closely around) the release of alpha3. Stas said that > he would be willing to update the README in a timely manner after finishing > a patch, in case we go for 3) or 4). I hope we can also find the time to > transfer any changes to docbook quickly after this. > > regards, > Lukas Kahwe Smith > mls@pooteeweet.org > > > > > -- > > > > -- Vesselin Kenashkov developer at www.webstudiobulgaria.com --- ## #40986 — Steph Fox — 2008-10-14T13:07:43+00:00 URL: https://externals.io/message/40906#40986 · In reply to: #40982 > Major changes like ripping the feature that most people are looking > forward to > in 5.3 out? 'Most people'? I would've expected 'most people' to be writing code that will run under 5.1 for at least the next couple of years! Experience tells me that takeup of new language elements is slow, and that 'most people' are likely to wait for PHP 5.3.1 or 5.3.2 before upgrading to 5.3 at all, precisely *because* it has a lot of new features. > 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. Except that it has never been part of PHP syntax. Except that it will make code harder to read/maintain. Except that there are cases where the intention will be ambiguous. > > […] > > 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. I'd love to see the public reaction if we get it badly wrong. I bet that lasts much, much longer than the five minute huff over withdrawal. - Steph --- ## #40987 — Scott MacVicar — 2008-10-14T13:16:02+00:00 URL: https://externals.io/message/40906#40987 · In reply to: #40906 Lukas Kahwe Smith wrote: > Hi All, > > There was an offline exchange, which generated a lot of good ideas, but > that failed to find agreement for one final proposal among the > participants. I had hoped that the results would have been mailed to > this list yesterday. Since I am going on yet another frisbee trip in > about an hour, I am putting on the thumb screws with this post. Stas > might update his proposal and Dmitry has a proposal that makes some more > modifications to be able to handle functions/constants in namespaces > without ambiguities. I will leave it to them to send their proposals to > the list. > > At this point I guess we have the choice between: > > 1) rip them out +1 I'd much rather see namespaces removed for 5.3 and a more thought out implementation for a future release. To be honest prefixing your classes isn't overly hard, so its not something most people will miss from 5.3. This discussion has already held up 5.3 enough for now and I'd rather not see BC badly broken when we "fix" some things in the future. Once we ship an implementation of Namespaces we're more or less stuck with it. Scott --- ## #40988 — Ryan Panning — 2008-10-14T13:19:14+00:00 URL: https://externals.io/message/40906#40988 · In reply to: #40977 Jochem Maas wrote: > > […] > +1 ... I concur with Steph's opinion Also +1 for taking them out. Namespaces should be saved for PHP 6 IMO as well. Now that the current namespaces have been tested there is at least a starting point for discussion. And that discussion has started as everyone knows. But I think that any decisions will not be made for a timely 5.3 release or the "quick and dirty" option will win. In the long run it needs to be done right, not in a hurry. --- ## #40989 — david.zuelke@bitextender.com — 2008-10-14T13:25:40+00:00 URL: https://externals.io/message/40906#40989 · In reply to: #40981 Am 14.10.2008 um 14:39 schrieb Steph Fox: > > […] > > People working with a development branch take their own chances. We > keep BC for released code, not for dev code. I agree 100% --- ## #40991 — david.zuelke@bitextender.com — 2008-10-14T13:27:50+00:00 URL: https://externals.io/message/40906#40991 · In reply to: #40975 Am 14.10.2008 um 14:10 schrieb Steph Fox: > > […] > I'm +1 on ripping out and leaving til 6.0. +1 from me, too. Getting it right takes time. If that means 6.0, fine. --- ## #40993 — Vesselin Kenashkov — 2008-10-14T13:35:17+00:00 URL: https://externals.io/message/40906#40993 · In reply to: #40988 I see the point and objections against "quick and dirty", but on the other hand the discussion about the namespaces started long time ago - two years already? If for two years there wasn't an agreement how they have to be implemented (or even whether to add them at all! because I see many comments in this sense) what are the reasons to think that in the next 5-6 months, when php6 will reach its "release stage" with the first alphas, this will be done? Even the namespaces dont go in php5.3 I think a solution/agreement has to be found quickly because it looks like php 6.0 could be in the same situation after few months. > Jochem Maas wrote: > > > […] > > Also +1 for taking them out. > > Namespaces should be saved for PHP 6 IMO as well. Now that the current > namespaces have been tested there is at least a starting point for > discussion. And that discussion has started as everyone knows. But I think > that any decisions will not be made for a timely 5.3 release or the "quick > and dirty" option will win. In the long run it needs to be done right, not > in a hurry. > > > -- > > > > -- Vesselin Kenashkov developer at www.webstudiobulgaria.com --- ## #40994 — Mikko Koppanen — 2008-10-14T13:42:54+00:00 URL: https://externals.io/message/40906#40994 · In reply to: #40991 On Tue, Oct 14, 2008 at 2:27 PM, David Zülke wrote: > Am 14.10.2008 um 14:10 schrieb Steph Fox: > > > […] > > +1 from me, too. Getting it right takes time. If that means 6.0, fine. +1 for removal. -- Mikko Koppanen --- Next page: https://externals.io/message/40906.md?page=2