# namespaces sanity: addition to RFC explaining why Stas's proposal doesn't work - Thread: https://externals.io/message/41107 - Original archive: https://news-web.php.net/php.internals/41107 - Started by Gregory Beaver on 2008-10-16T03:23:49+00:00 - Messages: 14 - 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 --- ## #41107 — Gregory Beaver — 2008-10-16T03:23:49+00:00 URL: https://externals.io/message/41107#41107 Hi again, I was asked to explain why I hadn't included ClassName->Method(); in the list of ideas that solve the ambiguity problem. I added a brief section to the RFC that does so: http://wiki.php.net/rfc/namespaceissues#why_stas_s_proposed_solution_doesn_t_work Thanks, Greg --- ## #41109 — Hannes Magnusson — 2008-10-16T06:12:33+00:00 URL: https://externals.io/message/41107#41109 · In reply to: #41107 > Hi again, > > I was asked to explain why I hadn't included ClassName->Method(); in the > list of ideas that solve the ambiguity problem. I added a brief section Can we please start small and then incrementally add more features? Lets start with classes only in namespaces in 5.3. -Hannes --- ## #41111 — Lester Caine — 2008-10-16T06:54:06+00:00 URL: https://externals.io/message/41107#41111 · In reply to: #41109 Hannes Magnusson wrote: > > […] > > Can we please start small and then incrementally add more features? > Lets start with classes only in namespaces in 5.3. The problem with that statement is that if it is used to ignore the other problems, then at some point it may be necessary to re-write all the new namespace code simply to allow additional features to be added! While I think it would be NICE to see a different separator, ':::' seems to annoy people, and using something else may cause problems for people with 'non-standard' keyboards who have trouble with some characters already? So 'USE' ? I'm I understanding things right on this one that one would 'define' the namespace in one sort of header file, and then add the use namespace to those files that build on the basic definition? I'm looking in particular here at a library like ADOdb, where 'adodb.inc.php' has a number of global functions which are then used by the various drivers. So 'adodb.inc.php' would define 'ADOdb' as a namespace and each driver would 'use namespace ADOdb' This seems a good example to work with and is the reason that simply dropping functions rang alarm bells with me. In fact it was the Date stuff from ADOdb that caused so much trouble with 'Date' in earlier releases so it seems appropriate to investigate how namespace would work with it? There are obviously other ways the problem could be solved, but a simply wrapper is the right approach initially? Or am I barking up the wrong tree? -- 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 --- ## #41112 — Hannes Magnusson — 2008-10-16T07:09:47+00:00 URL: https://externals.io/message/41107#41112 · In reply to: #41111 > Hannes Magnusson wrote: > > […] > > The problem with that statement is that if it is used to ignore the other > problems, then at some point it may be necessary to re-write all the new > namespace code simply to allow additional features to be added! tough luck. If it needs total rewrite in the future then it needs total rewrite now to support the additional features anyway. -Hannes --- ## #41121 — Steph Fox — 2008-10-16T13:04:32+00:00 URL: https://externals.io/message/41107#41121 · In reply to: #41112 Hannes, Lester... > > […] > > tough luck. If it needs total rewrite in the future then it needs > total rewrite now to support the additional features anyway. That was my argument for the entire first half of this week. If either of you had looked at Greg's latest idea, you'd know that it removes that problem entirely. Please go and look at his proposals at http://wiki.php.net/rfc/namespaceissues, and then vote? Thanks, - Steph --- ## #41122 — Justin Carlson — 2008-10-16T14:30:16+00:00 URL: https://externals.io/message/41107#41122 · In reply to: #41121 I vote for option 3. http://wiki.php.net/rfc/namespaceissues Seems like the best fit all around. Steph Fox wrote: > Hannes, Lester... > > > […] > > That was my argument for the entire first half of this week. If either > of you had looked at Greg's latest idea, you'd know that it removes > that problem entirely. > > Please go and look at his proposals at > http://wiki.php.net/rfc/namespaceissues, and then vote? > > Thanks, > > - Steph --- ## #41123 — Vesselin Kenashkov — 2008-10-16T14:34:25+00:00 URL: https://externals.io/message/41107#41123 · In reply to: #41122 The thread where your vote has to go is: [PHP-DEV] my last attempt at sanity with namespaces started also by Gregory. On Thu, Oct 16, 2008 at 5:30 PM, Justin Carlson wrote: > > I vote for option 3. > > http://wiki.php.net/rfc/namespaceissues > > Seems like the best fit all around. > > > > > > Steph Fox wrote: > > > […] > > -- > > > > -- Vesselin Kenashkov developer at www.webstudiobulgaria.com --- ## #41129 — Stanislav Malyshev — 2008-10-16T15:17:08+00:00 URL: https://externals.io/message/41107#41129 · In reply to: #41107 Hi! Gregory Beaver wrote: > Hi again, > > I was asked to explain why I hadn't included ClassName->Method(); in the > list of ideas that solve the ambiguity problem. I added a brief section > to the RFC that does so: > > http://wiki.php.net/rfc/namespaceissues#why_stas_s_proposed_solution_doesn_t_work What you wrote is incorrect - it does not require changing syntax everywhere, but only in very rare cases where actual ambiguity exists. Actual ambiguity would exist only when different people without any communication between them or common design plan work on one namespace (which should never happen, but we know our users, so we give them some help even if they don't follow good practices). There's absolutely no need to rewrite any existing code. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #41131 — Stanislav Malyshev — 2008-10-16T15:20:03+00:00 URL: https://externals.io/message/41107#41131 · In reply to: #41111 Hi! > The problem with that statement is that if it is used to ignore the > other problems, then at some point it may be necessary to re-write all > the new namespace code simply to allow additional features to be added! So? We rewrote pretty much every other part of PHP - engine, object model, filesystem, etc. - and nobody died. Suddently with this particular feature there's tremendous fear of commitment. But we aren't going anywhere by sitting and talking about "what if". We get anywhere only by releasing features and seeing what they do. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #41145 — Greg Beaver — 2008-10-16T17:04:22+00:00 URL: https://externals.io/message/41107#41145 · In reply to: #41131 Stanislav Malyshev wrote: > Hi! > > > […] > > So? We rewrote pretty much every other part of PHP - engine, object > model, filesystem, etc. - and nobody died. Suddently with this > particular feature there's tremendous fear of commitment. But we aren't > going anywhere by sitting and talking about "what if". We get anywhere > only by releasing features and seeing what they do. My point is that for this code: The proposal does not solve the name conflict. If no one rewrites their code to use Classname->Method(), then no one will be protected from the ambiguity. I am thinking of the case where a user adds a new feature to their existing code that uses a 3rd-party library with namespaced functions that accidentally conflict with the user's classes without their knowledge. As third-party libraries become easier to distribute (which both phar and pyrus plan to do), this will become more of an issue. Our experience with other changes forced upon existing code has shown that user inertia is high, and we can't expect to fix things simply by asking the users to rewrite their code unless PHP tells them to with `E_STRICT` or other warnings. Should I add this to the explanation or is it clear enough? Greg --- ## #41153 — Stanislav Malyshev — 2008-10-16T17:26:16+00:00 URL: https://externals.io/message/41107#41153 · In reply to: #41145 Hi! > My point is that for this code: > > Classname::Method(); > ?> > > The proposal does not solve the name conflict. If no one rewrites their Right, it does not. So doesn't yours - you need to modify the code in both cases. > code to use Classname->Method(), then no one will be protected from the > ambiguity. I am thinking of the case where a user adds a new feature to If nobody changes existing code then there's no ambiguity by definition. If the code is changed, then of course one needs to change it in the right way, there's no way around that - you always can think of some wrong code that works, well, wrong. > their existing code that uses a 3rd-party library with namespaced > functions that accidentally conflict with the user's classes without If you use 3rd party library that has same namespace as yours somebody had screwed up here - either you used namespace that doesn't belong to you or they used namespace that doesn't belong to them. In both cases the fix is un-screw-up the naming. > their knowledge. As third-party libraries become easier to distribute > (which both phar and pyrus plan to do), this will become more of an issue. Nobody should put their classes in PEAR namespace unless they are part of PEAR library, thus this scenario - when somebody outside of PEAR has conflict with PEAR functions/classes - is imaginary. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #41151 — Lester Caine — 2008-10-16T17:27:49+00:00 URL: https://externals.io/message/41107#41151 · In reply to: #41111 Since this got cut without am answer I'll repeat it since *I* would still like to know the answer! Lester Caine wrote: > So 'USE' ? > I'm I understanding things right on this one that one would 'define' the > namespace in one sort of header file, and then add the use namespace to > those files that build on the basic definition? I'm looking in > particular here at a library like ADOdb, where 'adodb.inc.php' has a > number of global functions which are then used by the various drivers. > So 'adodb.inc.php' would define 'ADOdb' as a namespace and each driver > would > 'use namespace ADOdb' > > This seems a good example to work with and is the reason that simply > dropping functions rang alarm bells with me. In fact it was the Date > stuff from ADOdb that caused so much trouble with 'Date' in earlier > releases so it seems appropriate to investigate how namespace would work > with it? There are obviously other ways the problem could be solved, but > a simply wrapper is the right approach initially? > > Or am I barking up the wrong tree? If #3 is intended to work this way then it gets my vote. Trying to apply namespace something substantial and understanding where the code needs to be changed to work seems more logical than some of the academic examples. -- 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 --- ## #41166 — Greg Beaver — 2008-10-16T20:36:15+00:00 URL: https://externals.io/message/41107#41166 · In reply to: #41153 Stanislav Malyshev wrote: > Hi! > > > […] > > Right, it does not. So doesn't yours - you need to modify the code in > both cases. the solution I proposed emits an `E_WARNING` on the conflict. Greg --- ## #41167 — Stanislav Malyshev — 2008-10-16T20:50:44+00:00 URL: https://externals.io/message/41107#41167 · In reply to: #41166 Hi! > > […] > the solution I proposed emits an `E_WARNING` on the conflict. You proposed a number of solutions, apparently. That's why I asked to restrict the number of variants - even people who watch the discussion can't be sure what we are talking about now. Do you propose to _always_ throw `E_WARNING` even if there was no actual conflict? Then I am against it - in 99.9% of the code this warning would be useless and would only annoy people. If you propose to throw warning only if actual conflict exists - the question stays how do you know it exists. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com