# namespaces and alpha3 - Thread: https://externals.io/message/41003 - Original archive: https://news-web.php.net/php.internals/41003 - Started by Tony Bibbs on 2008-10-14T17:54:34+00:00 - Messages: 38 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/41003.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 --- ## #41003 — Tony Bibbs — 2008-10-14T17:54:34+00:00 URL: https://externals.io/message/41003#41003 Hi Steph, [snip] 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? [/snip] I don't think Stas is implying not to test it. We are talking about another 5.3 alpha, right? Clearly the beta and RC releases will allow the community to help test and I really do believe this will get a lot of community use in beta/RC mode. What theories are you referring to that need more exploration that can't be done yet for 5.3? Obviously I'm in favor of seeing this in 5.3 but if it does get postponed to 6.0 it would be nice to see a plan of attack for finishing the implementation immediately after the 5.3 release. Without such a plan I fear Stas' prediction of more of nothing will come true. --Tony --- ## #41005 — Steph Fox — 2008-10-14T18:07:50+00:00 URL: https://externals.io/message/41003#41005 · In reply to: #41003 Hi Tony, > I don't think Stas is implying not to test it. Which proposal do you think he's implying not to test? And which of the other three proposals on offer do you think should go out there, bearing in mind that once the thing's released it can't be changed? - Steph --- ## #41007 — Lester Caine — 2008-10-14T18:29:52+00:00 URL: https://externals.io/message/41003#41007 · In reply to: #41005 Steph Fox wrote: > Hi Tony, > > > […] > > Which proposal do you think he's implying not to test? And which of the > other three proposals on offer do you think should go out there, bearing > in mind that once the thing's released it can't be changed? I think that is the bottom line! Can anybody come up with a good case for why functions and constant should be 'thrown out with the bath water' ? If there is a majority for ignoring a major section of PHP and restricting new stuff to be only Class based, then we can safely rip functions and constant out and ignore them and go with the current restricted code? I get the feeling however that if namespace is to be usable in the SHORT term, then wrapping functions and constants is essential simply to wrap legacy stuff while it is converted to objects? If there was a clear solution to a complete handling of namespace, then there would not be a problem, but currently there are some big holes that can not be plugged later if the CURRENT code is released? So put it back on the drawing board and try and plug the holes rather than holding up 5.3. While there may have been talking about namespace for years, the problems were never fully appreciated? Now that they have been documented and some of the pros and cons discussed, it is clear that a decision to force the current solution through will cause as many problems later on? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #41009 — Stanislav Malyshev — 2008-10-14T18:42:44+00:00 URL: https://externals.io/message/41003#41009 · In reply to: #41007 Hi! > Can anybody come up with a good case for why functions and constant > should be 'thrown out with the bath water' ? I can name two: 1. Most (not all, I know, but most) of the use cases for namespaces are in the OO realm, and most of the problems they are to serve come from that realm too. So at least initially most of the active users, which wait for it impatiently, are OO users, and classes are the thing the care the most about. 2. Everything becomes so much simpler with only classes. Classes and functions have very different usage patterns in PHP, so if we try to serve them both we inevitably encounter some "inconsistencies" in how they are served, because of the different usage patterns, which may be a problem for some purists. I personally don't care too much for "inconsistencies" if they serve the user - i.e. allow to do useful things easier - but I know there are other approaches. Please note that doesn't mean we _must_ drop them - I am just presenting the argument for it, I am aware of the existence of the arguments against too. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #41011 — Steph Fox — 2008-10-14T19:04:23+00:00 URL: https://externals.io/message/41003#41011 · In reply to: #41009 > I can name two: > 1. Most (not all, I know, but most) of the use cases for namespaces are in > the OO realm, and most of the problems they are to serve come from that > realm too. So at least initially most of the active users, which wait for > it impatiently, are OO users, and classes are the thing the care the most > about. > 2. Everything becomes so much simpler with only classes. Classes and > functions have very different usage patterns in PHP, so if we try to serve > them both we inevitably encounter some "inconsistencies" in how they are > served, because of the different usage patterns, which may be a problem > for some purists. I personally don't care too much for "inconsistencies" > if they serve the user - i.e. allow to do useful things easier - but I > know there are other approaches. FWIW, I agree with everything Stas says here. > Please note that doesn't mean we _must_ drop them - I am just presenting > the argument for it, I am aware of the existence of the arguments against > too. The problem is we can't know whether restricting *future* evolution in namespace support is going to turn out to be a good idea. - Steph --- ## #41015 — Stanislav Malyshev — 2008-10-14T19:22:08+00:00 URL: https://externals.io/message/41003#41015 · In reply to: #41011 Hi! > The problem is we can't know whether restricting *future* evolution in > namespace support is going to turn out to be a good idea. I think we have now all the information we could have without really having it in the wild. Yes, we can make a mistake based on this information, but I see no use in sitting there and doing nothing but asking ourselves "do we make a mistake?". We are not advancing with it that way. If you can name something that could further our progress here and that can be done after 5.3 but can't be done right now - name it. Otherwise I see absolutely no reason in postponing the decision. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #41017 — Steph Fox — 2008-10-14T19:43:25+00:00 URL: https://externals.io/message/41003#41017 · In reply to: #41015 > If you can name something that could further our progress here and that > can be done after 5.3 but can't be done right now - name it. Broad-scale testing with the ability to alter the implementation should problems become apparent. > Otherwise I see absolutely no reason in postponing the decision. > -- > Stanislav Malyshev, Zend Software Architect > stas@zend.com http://www.zend.com/ > (408)253-8829 MSN: stas@zend.com --- ## #41018 — Stanislav Malyshev — 2008-10-14T19:50:06+00:00 URL: https://externals.io/message/41003#41018 · In reply to: #41017 Hi! > Broad-scale testing with the ability to alter the implementation should > problems become apparent. What you are talking about? Who'll be doing this broad-scale testing, when? -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #41019 — Arvids Godjuks — 2008-10-14T19:53:11+00:00 URL: https://externals.io/message/41003#41019 · In reply to: #41015 People, why you just don't change the namespace separator to something except :: and sole all the problems one and for all? God damn, use :> if you need - just push it out working! Most of my fellow programmers are just sick with reading internals discussing how to throw a feathure away because ambitity problem with :: can't be solved totaly. Me too, mostly I just skip namespace topics. Make a solid decision. Find the guts to change that misserable :: separator to something else (:> for example) and be done with it - you are like children who can't deside whose toy is it with thouse namespaces! Take a break for 2-3 days and look back on what you are arguing about - you made a problem from nothing! Originaly no one thought about :: can be used with namespaces,now you are trying to fix it but you can't.This is a design issue, you can't solve it without breaking BC and getting everybody happy. By changing separator you will reach all goals at one shot - functions, classes, constants will be alowed in namespaces. That is what userland developers what. Give that to them! --- ## #41021 — Steph Fox — 2008-10-14T20:01:49+00:00 URL: https://externals.io/message/41003#41021 · In reply to: #41018 > > […] > > What you are talking about? Who'll be doing this broad-scale testing, > when? Users. And I think Lukas' approach is good - use alpha as a testing ground. - Steph --- ## #41022 — david.zuelke@bitextender.com — 2008-10-14T20:02:03+00:00 URL: https://externals.io/message/41003#41022 · In reply to: #41019 I recommend you and your fellow programmers read the discussion again. It's nost just about syntax. > People, why you just don't change the namespace separator to something > except :: and sole all the problems one and for all? God damn, > use :> if you > need - just push it out working! Most of my fellow programmers are > just sick > with reading internals discussing how to throw a feathure away because > ambitity problem with :: can't be solved totaly. Me too, mostly I > just skip > namespace topics. > > Make a solid decision. Find the guts to change that misserable :: > separator > to something else (:> for example) and be done with it - you are like > children who can't deside whose toy is it with thouse namespaces! > Take a > break for 2-3 days and look back on what you are arguing about - you > made a > problem from nothing! Originaly no one thought about :: can be used > with > namespaces,now you are trying to fix it but you can't.This is a design > issue, you can't solve it without breaking BC and getting everybody > happy. > > By changing separator you will reach all goals at one shot - > functions, > classes, constants will be alowed in namespaces. That is what userland > developers what. Give that to them! --- ## #41023 — Stanislav Malyshev — 2008-10-14T20:03:00+00:00 URL: https://externals.io/message/41003#41023 · In reply to: #41021 Hi! > Users. And I think Lukas' approach is good - use alpha as a testing ground. Namespaces are for big projects. Staring big project using namespaces when it's not even clear they'll be in 5.3 is an insane risk, nobody would do it. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #41027 — Steph Fox — 2008-10-14T20:38:29+00:00 URL: https://externals.io/message/41003#41027 · In reply to: #41023 > Namespaces are for big projects. Staring big project using namespaces when > it's not even clear they'll be in 5.3 is an insane risk, nobody would do > it. Only 8 hours ago, one Jean-Phillipe Serafin 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..." and there were further objections on the grounds that namespace support has been 'announced' on php.net. I agree with you that it's an insane risk, but that doesn't mean nobody does it. - Steph --- ## #41030 — Stanislav Malyshev — 2008-10-14T20:55:56+00:00 URL: https://externals.io/message/41003#41030 · In reply to: #41027 Hi! > Only 8 hours ago, one Jean-Phillipe Serafin 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..." and there were further objections on the grounds that namespace > support has been 'announced' on php.net. Exactly. This is because we announced it on conferences, talked about it on lists and basically made a lot of noise about how cool it would be very soon. And people believed us and took the risk. And now you propose to teach them the lesson that trusting PHP core developers that they actually deliver is a bad idea. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #41031 — Josh Davis — 2008-10-14T21:01:04+00:00 URL: https://externals.io/message/41003#41031 · In reply to: #41027 2008/10/14 Steph Fox : > > Only 8 hours ago, one Jean-Phillipe Serafin 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..." and > there were further objections on the grounds that namespace support has been > 'announced' on php.net. I'd like to point out that those people started working with namespaces *before* the idea of dropping them (or postponing them to PHP 6) appeared on the list. I doubt those people would have done the same if they had been told that namespaces may very well not be available until PHP 6. Namespace support in 5.3 received quite a lot of coverage this year through blogs, articles and presentations, that's why some people started implementing them or prepared to migrate their codebase. Now if they're told it's postponed indefinitely (until PHP 6 gets a tentative schedule) they'll feel burned and they'll think twice before investing any time in testing new features in future releases. I think that's what Stas meant, people would not take the risk to implement such extensive changes without the assurance that namespace will be available. Those who already did were pretty sure that 5.3 would have namespaces. JD --- ## #41032 — Steph Fox — 2008-10-14T21:04:41+00:00 URL: https://externals.io/message/41003#41032 · In reply to: #41030 Stas... > And people believed us and took the risk. Which you just said they wouldn't do. > And now you propose to teach them the lesson that trusting PHP core > developers that they actually deliver is a bad idea. It seems a sounder policy than teaching them they can't trust that what is actually delivered will be robust! - Steph --- ## #41033 — Lukas Kahwe Smith — 2008-10-14T21:08:04+00:00 URL: https://externals.io/message/41003#41033 · In reply to: #41030 > Hi! > > > […] > > Exactly. This is because we announced it on conferences, talked > about it on lists and basically made a lot of noise about how cool > it would be very soon. And people believed us and took the risk. And > now you propose to teach them the lesson that trusting PHP core > developers that they actually deliver is a bad idea. just to clarify .. there are solutions on the table that people have worked on hard and that are believed to solve the issues, albeit that come with some carefully chosen baggage. We are not discussing how to do things (this goes to Nathan's reply that just came in). if we remove namespaces now, after talking about it, prodding it, asking people to try it out, getting a lot of general positive vibe for this feature, coming up with a solution .. then i think we are doing our users a disservices. the proposals are not half baked omg we need to get this done quickly for alpha3 (note that alpha3 was delayed to get to this point). of course waiting longer always gives the opportunity to improve tweak etc. but given that we might as wel stop releasing software altogether if we are unwilling to take the risk of a mistake. anyways, given the current state most people voted to remove namespaces from PHP 5.3. i assume that all people that casted these votes were (and still are) confident that they actually know what they voted on. maybe some of the people involved in finding the current proposals will try to document the issues and the solution (and the issues in these solutions) onces more in the hopes of changing the minds of some of the people that have voted. i personally have spend enough time on namespaces for now that i will not involve myself in that any further for now. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #41034 — Steph Fox — 2008-10-14T21:12:43+00:00 URL: https://externals.io/message/41003#41034 · In reply to: #41031 Hi Josh, > I'd like to point out that those people started working with > namespaces *before* the idea of dropping them (or postponing them to > PHP 6) appeared on the list. I doubt those people would have done the > same if they had been told that namespaces may very well not be > available until PHP 6. Surely everyone can see the very public ongoing discussions on internals@ over the course of this and last year? > Namespace support in 5.3 received quite a lot of coverage this year > through blogs, articles and presentations, that's why some people > started implementing them or prepared to migrate their codebase. Now > if they're told it's postponed indefinitely (until PHP 6 gets a > tentative schedule) they'll feel burned and they'll think twice before > investing any time in testing new features in future releases. There's a very big difference between 'testing' and 'preparing to migrate a codebase'. > I think that's what Stas meant, people would not take the risk to > implement such extensive changes without the assurance that namespace > will be available. Those who already did were pretty sure that 5.3 > would have namespaces. And of course those same people don't mind a bit if the implementation has changed 8 times in the last 6 months, because they understand that they're testing a moving target. No? - Steph --- ## #41036 — Lukas Kahwe Smith — 2008-10-14T21:14:50+00:00 URL: https://externals.io/message/41003#41036 · In reply to: #41035 > > […] > > I think we should wait and see what Greg et al come up with. If > they're close to a solution they believe will be acceptable to all, > we're voting too soon. err .. you misunderstood me .. Dmitry wasnt happy with his approach .. last I heard Greg also stopped exploring his alternative approaches. so dont hold you breath. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #41035 — Steph Fox — 2008-10-14T21:15:06+00:00 URL: https://externals.io/message/41003#41035 · In reply to: #41033 > anyways, given the current state most people voted to remove namespaces > from PHP 5.3. i assume that all people that casted these votes were (and > still are) confident that they actually know what they voted on. maybe > some of the people involved in finding the current proposals will try to > document the issues and the solution (and the issues in these solutions) > onces more in the hopes of changing the minds of some of the people that > have voted. i personally have spend enough time on namespaces for now > that i will not involve myself in that any further for now. I think we should wait and see what Greg et al come up with. If they're close to a solution they believe will be acceptable to all, we're voting too soon. - Steph --- ## #41037 — Stanislav Malyshev — 2008-10-14T21:26:52+00:00 URL: https://externals.io/message/41003#41037 · In reply to: #41034 Hi! > Surely everyone can see the very public ongoing discussions on > internals@ over the course of this and last year? Surely everyone in PHP world reads internals@ and can follow all the twists and turns of all the discussion. You must be kidding. > And of course those same people don't mind a bit if the implementation > has changed 8 times in the last 6 months, because they understand that > they're testing a moving target. No? It wasn't changed in any substantial way even 2 times, let's not exaggerate. And most things under discussion now - except for removing functions which 99% of these people don't need anyway - are very special cases which while exist theoretically are easily avoided in practical code by following code style guidelines, thus ensuring whatever comes out would not have critical influence on the code. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #41038 — Nathan Rixham — 2008-10-14T21:44:02+00:00 URL: https://externals.io/message/41003#41038 · In reply to: #41037 Stanislav Malyshev wrote: > Hi! > > > […] > > Surely everyone in PHP world reads internals@ and can follow all the > twists and turns of all the discussion. You must be kidding. > most of the frequenters of @general do --- ## #41039 — Vesselin Kenashkov — 2008-10-14T21:50:08+00:00 URL: https://externals.io/message/41003#41039 · In reply to: #41037 > Hi! > > Surely everyone can see the very public ongoing discussions on internals@over the course of this and last year? > > […] > > Surely everyone in PHP world reads internals@ and can follow all the > twists and turns of all the discussion. You must be kidding. > I think the same - the noise was high, many people know that "namespaces are coming". I personally tried to follow all of the threads on the namespace discussions @internals in the last years, but honestly - I couldn't. From my personal statistics - almost no developers (as % from the total) outside the "php core team" could/had the time. > > > And of course those same people don't mind a bit if the implementation has > > […] > > It wasn't changed in any substantial way even 2 times, let's not > exaggerate. And most things under discussion now - except for removing > functions which 99% of these people don't need anyway - are very special > cases which while exist theoretically are easily avoided in practical code > by following code style guidelines, thus ensuring whatever comes out would > not have critical influence on the code. > I've implemented several projects using namespaces; a complex use - with autoload, file hierarchy corresponding to the namespace one, with namespaced constants and functions, and nothing was broken while I was updating the php5.3-dev, so looks like nothing major (related to ns) was changed. "...are easily avoided in practical code by following code style guidelines" - I think this can be applied to the current implementation and just avoid naming static class and a namespace in with repeating names (in the same position in the hierarchy), to avoid the ambiguity, can it? Last thought - now php5.3 is in alpha release stage - what is the better time to try something new? Change the proposal to whatever you find is best and release it. But posponing it the opportunity will be missed (until the next one of php6 alpha cycle when the situation will be repeated). Steph, I see you point (thank you for the exmplanation), I just think that whatever the solution is will be better to have something in the alpha at least to gather feedback. Someone in the previous messages said that he is affraid that after the release in the alpha of a not-so-good-namespace-implementation there might be public pressure to preserve it. But I think this is not that bad, because means that the developers liked it. In short - use the alpha cycle to propose solutions even if they get scrapped at the end. At least you will know what is not working (wheter for technical or human reasons) and then a better implementation can be proposed for 6. > -- > Stanislav Malyshev, Zend Software Architect > stas@zend.com http://www.zend.com/ > (408)253-8829 MSN: stas@zend.com > > -- > > > > -- Vesselin Kenashkov developer at www.webstudiobulgaria.com --- ## #41040 — Andi Gutmans — 2008-10-14T22:30:34+00:00 URL: https://externals.io/message/41003#41040 · In reply to: #41036 > -----Original Message----- > From: Lukas Kahwe Smith [mailto:mls@pooteeweet.org] > Sent: Tuesday, October 14, 2008 2:15 PM > To: Steph Fox > Cc: Stas Malyshev; PHP internals > Subject: Re: [PHP-DEV] namespaces and alpha3 > > err .. you misunderstood me .. Dmitry wasnt happy with his approach .. > last I heard Greg also stopped exploring his alternative approaches. > so dont hold you breath. As I said, I talked to Dmitry today and he was OK with it. I do think there's also a good chance to make progress with Greg. I suggest to give it a couple of more days. In any case, as I said, the real issues that are being discussed are mostly marginal and I think a broader alpha/beta when the time comes will help get the necessary feedback from people who really play around with it and/or bring up other issues. Andi --- ## #41041 — Jochem Maas — 2008-10-14T22:49:37+00:00 URL: https://externals.io/message/41003#41041 · In reply to: #41040 Andi Gutmans schreef: > > […] > > As I said, I talked to Dmitry today and he was OK with it. > I do think there's also a good chance to make progress with Greg. I'd like to reiterate that I gave a +1 on posponing till 6.0. If it turns out that some form of the latest proposal (by Stas) get's an OK from Greg then I'd change my vote (for what it's worth) to align with Greg's ... I followed Greg's analysis and proposed solutions very closely, if he end's up giving an OK to some form of Stas' latest proposal then that would likely indicate a situation/feature that is really worth releasing. basically: if Greg gives a 'thumbs up' all the nay-sayers should take note! he was probably the biggest nay-sayer and he did his homework more thoroughly than just about anyone else I've come accross. > I suggest to give it a couple of more days. In any case, as I said, the > real issues that are being discussed are mostly marginal and I think a > broader alpha/beta when the time comes will help get the necessary > feedback from people who really play around with it and/or bring up > other issues. > > Andi --- Next page: https://externals.io/message/41003.md?page=2