# Question about Namespace patch - Thread: https://externals.io/message/31157 - Original archive: https://news-web.php.net/php.internals/31157 - Started by Markus Fischer on 2007-07-22T09:04:21+00:00 - Messages: 62 - Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/31157.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 --- ## #31157 — Markus Fischer — 2007-07-22T09:04:21+00:00 URL: https://externals.io/message/31157#31157 Hi, I've a few questions about the namespace patch: 1) Why is "import Foo" a no-op? Shouldn't it import everything define inside Foo? 2) How can I import all classes from a namespace at once? Like question 1) actually. "import Foo::*" doesn't work. 3) Shouldn't there be an error when importing a class which already existing in the current scope? Example ---------------8<-------------------- ns2.php: php ns1.php Namespace class ---------------8<-------------------- I read the thread an I know that I can still call access the global class with ::Bar ... but is this a intuitive behaviour? thanks, - Markus --- ## #31163 — Stanislav Malyshev — 2007-07-23T03:36:00+00:00 URL: https://externals.io/message/31157#31163 · In reply to: #31157 > 1) Why is "import Foo" a no-op? > Shouldn't it import everything define inside Foo? No, it shouldn't. > 2) How can I import all classes from a namespace at once? Use namespace::class. > 3) Shouldn't there be an error when importing a class which already > existing in the current scope? Example I think there should be. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #31165 — Derick Rethans — 2007-07-23T06:54:55+00:00 URL: https://externals.io/message/31157#31165 · In reply to: #31163 > > […] > > Use namespace::class. That's not the answer to the question. Markus was asking how to import *all* classes from a namespace at *once*. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org --- ## #31166 — Jeremy Privett — 2007-07-23T06:59:48+00:00 URL: https://externals.io/message/31157#31166 · In reply to: #31165 And that's exactly why this implementation isn't intuitive. As far as I can see from the way it's been explained, so far, that is not possible. Jeremy -----Original Message----- From: Derick Rethans [mailto:derick@php.net] Sent: Monday, July 23, 2007 12:55 AM To: Stanislav Malyshev Cc: Markus Fischer; internals Subject: Re: [PHP-DEV] Question about Namespace patch > > […] > > Use namespace::class. That's not the answer to the question. Markus was asking how to import *all* classes from a namespace at *once*. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org --- ## #31167 — Stanislav Malyshev — 2007-07-23T07:37:35+00:00 URL: https://externals.io/message/31157#31167 · In reply to: #31165 > > […] > > That's not the answer to the question. Markus was asking how to import > *all* classes from a namespace at *once*. That IS the answer. You don't. You use namespace::class instead. The whole purpose was to get them OUT of the global space, no reason to bring them back in. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #31168 — Stanislav Malyshev — 2007-07-23T07:38:58+00:00 URL: https://externals.io/message/31157#31168 · In reply to: #31166 > And that's exactly why this implementation isn't intuitive. As far as I > can see from the way it's been explained, so far, that is not possible. No implementation is "intuitive", unless by "intuitive" you mean "works as in that other language I know". Too bad in each of these languages it works differently :) -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #31169 — Jeremy Privett — 2007-07-23T08:01:39+00:00 URL: https://externals.io/message/31157#31169 · In reply to: #31168 Stanislav, Absolutely not the case. Take a look at C++, C#, even Python. The "namespaces" implementation of those languages is mostly consistent (even if Python doesn't call it that). You're not helping developers at all with this implementation. If you're working with a large library and have to import a lot of classes, the way this works is nothing but a pain. We would be better off not using namespaces at all, in this case. Thus, the problem has not been solved. Also, for the implementation to be complete, Core Developers and Extension Developers would need to namespace their classes / functions. And that, undoubtedly, is a LOT of work. I can understand this being the justification for implementing namespaces in the way it's been implemented, because all of this other stuff in the global namespace, but you still need to offer developers *some* way of importing everything out of a namespace. I absolutely will have upwards to close to 25 - 30 classes in a single namespace. And sometimes more. To be able to import them all is an absolute necessity for this implementation to be remotely feasible. Having an import block at the top of files that's that huge just doesn't make any sense. And that doesn't even consider the fact that I may be using OTHER libraries as well that may be namespaced. PEAR is a perfect example of this. Look at all the libraries that exist there. I would absolutely love to just: import PEAR; import PEAR::HTTP; import PEAR::Image; And not have to worry about going through and picking out every little individual class that I need. And with all of the languages I mentioned before, that is *exactly* how it works. Of course, we're back to the namespacing of the PHP Core and Extensions. Which is really the main blocker to any serious namespaces implementation, beyond what's currently patched to HEAD today, correct? I hope you can better see my viewpoint, now that I actually had the time to sit down and type out a more coherent reply. This implementation and the unicode.semantics discussion have to be the most frustrating points PHP6 has for me, right now. Thanks. --- Jeremy Privett Software Developer Peak8 Solutions -----Original Message----- From: Stanislav Malyshev [mailto:stas@zend.com] Sent: Monday, July 23, 2007 1:39 AM To: Jeremy Privett Cc: Derick Rethans; Markus Fischer; internals Subject: Re: [PHP-DEV] Question about Namespace patch > And that's exactly why this implementation isn't intuitive. As far as I > can see from the way it's been explained, so far, that is not possible. No implementation is "intuitive", unless by "intuitive" you mean "works as in that other language I know". Too bad in each of these languages it works differently :) -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #31170 — Alexey Zakhlestin — 2007-07-23T08:13:40+00:00 URL: https://externals.io/message/31157#31170 · In reply to: #31169 In reality, it is rarely (almost never) needed to import all the classes. Usually you need 2–4 per file, not more, and importing just what you really need is the step to a clean design. You don't need to import every class which is used implicitly, only those which are explicitly used. > Stanislav, > > Absolutely not the case. Take a look at C++, C#, even Python. The > "namespaces" implementation of those languages is mostly consistent > (even if Python doesn't call it that). > > You're not helping developers at all with this implementation. If you're > working with a large library and have to import a lot of classes, the > way this works is nothing but a pain. We would be better off not using > namespaces at all, in this case. Thus, the problem has not been solved. > > Also, for the implementation to be complete, Core Developers and > Extension Developers would need to namespace their classes / functions. > And that, undoubtedly, is a LOT of work. I can understand this being the > justification for implementing namespaces in the way it's been > implemented, because all of this other stuff in the global namespace, > but you still need to offer developers *some* way of importing > everything out of a namespace. I absolutely will have upwards to close > to 25 - 30 classes in a single namespace. And sometimes more. To be able > to import them all is an absolute necessity for this implementation to > be remotely feasible. Having an import block at the top of files that's > that huge just doesn't make any sense. And that doesn't even consider > the fact that I may be using OTHER libraries as well that may be > namespaced. > > PEAR is a perfect example of this. Look at all the libraries that exist > there. I would absolutely love to just: > > import PEAR; > import PEAR::HTTP; > import PEAR::Image; > > And not have to worry about going through and picking out every little > individual class that I need. And with all of the languages I mentioned > before, that is *exactly* how it works. Of course, we're back to the > namespacing of the PHP Core and Extensions. Which is really the main > blocker to any serious namespaces implementation, beyond what's > currently patched to HEAD today, correct? > > I hope you can better see my viewpoint, now that I actually had the time > to sit down and type out a more coherent reply. This implementation and > the unicode.semantics discussion have to be the most frustrating points > PHP6 has for me, right now. > > Thanks. > > --- > Jeremy Privett > Software Developer > Peak8 Solutions > > -----Original Message----- > From: Stanislav Malyshev [mailto:stas@zend.com] > Sent: Monday, July 23, 2007 1:39 AM > To: Jeremy Privett > Cc: Derick Rethans; Markus Fischer; internals > Subject: Re: [PHP-DEV] Question about Namespace patch > > > […] > I > > […] > possible. > > No implementation is "intuitive", unless by "intuitive" you mean "works > as in that other language I know". Too bad in each of these languages it > > works differently :) > -- > Stanislav Malyshev, Zend Software Architect > stas@zend.com http://www.zend.com/ > (408)253-8829 MSN: stas@zend.com > > -- > > > > -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ --- ## #31171 — Jeremy Privett — 2007-07-23T08:22:33+00:00 URL: https://externals.io/message/31157#31171 · In reply to: #31170 Alexey, I honestly wish that were the case with the situation I'm dealing with at my current job. And I know a lot of people that are absolutely in the same boat as I am. I definitely understand your reasoning here, but we're obviously talking about design versus convenience. This is one of those situations where convenience makes the difference. Was there ever a decision on whether or not the patch is going to be backported to PHP5? I think I'll grab a PHP6 snapshot and toy around with the implementation a bit. Who knows ... it may grow on me. We'll see. Thanks. --- Jeremy Privett Software Developer Peak8 Solutions -----Original Message----- From: Alexey Zakhlestin [mailto:indeyets@gmail.com] Sent: Monday, July 23, 2007 2:14 AM To: Jeremy Privett Cc: Stanislav Malyshev; Derick Rethans; Markus Fischer; internals Subject: Re: [PHP-DEV] Question about Namespace patch In reality, it is rarely (almost never) needed to import all the classes. Usually you need 2-4 per file, not more, and importing just what you really need is the step to a clean design. You don't need to import every class which is used implicitly, only those which are explicitly used. > Stanislav, > > Absolutely not the case. Take a look at C++, C#, even Python. The > "namespaces" implementation of those languages is mostly consistent > (even if Python doesn't call it that). > > You're not helping developers at all with this implementation. If you're > working with a large library and have to import a lot of classes, the > way this works is nothing but a pain. We would be better off not using > namespaces at all, in this case. Thus, the problem has not been solved. > > Also, for the implementation to be complete, Core Developers and > Extension Developers would need to namespace their classes / functions. > And that, undoubtedly, is a LOT of work. I can understand this being the > justification for implementing namespaces in the way it's been > implemented, because all of this other stuff in the global namespace, > but you still need to offer developers *some* way of importing > everything out of a namespace. I absolutely will have upwards to close > to 25 - 30 classes in a single namespace. And sometimes more. To be able > to import them all is an absolute necessity for this implementation to > be remotely feasible. Having an import block at the top of files that's > that huge just doesn't make any sense. And that doesn't even consider > the fact that I may be using OTHER libraries as well that may be > namespaced. > > PEAR is a perfect example of this. Look at all the libraries that exist > there. I would absolutely love to just: > > import PEAR; > import PEAR::HTTP; > import PEAR::Image; > > And not have to worry about going through and picking out every little > individual class that I need. And with all of the languages I mentioned > before, that is *exactly* how it works. Of course, we're back to the > namespacing of the PHP Core and Extensions. Which is really the main > blocker to any serious namespaces implementation, beyond what's > currently patched to HEAD today, correct? > > I hope you can better see my viewpoint, now that I actually had the time > to sit down and type out a more coherent reply. This implementation and > the unicode.semantics discussion have to be the most frustrating points > PHP6 has for me, right now. > > Thanks. > > --- > Jeremy Privett > Software Developer > Peak8 Solutions > > -----Original Message----- > From: Stanislav Malyshev [mailto:stas@zend.com] > Sent: Monday, July 23, 2007 1:39 AM > To: Jeremy Privett > Cc: Derick Rethans; Markus Fischer; internals > Subject: Re: [PHP-DEV] Question about Namespace patch > > > […] as > I > > […] > possible. > > No implementation is "intuitive", unless by "intuitive" you mean "works > as in that other language I know". Too bad in each of these languages it > > works differently :) > -- > Stanislav Malyshev, Zend Software Architect > stas@zend.com http://www.zend.com/ > (408)253-8829 MSN: stas@zend.com > > -- > > > > -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ --- ## #31172 — Stanislav Malyshev — 2007-07-23T08:26:02+00:00 URL: https://externals.io/message/31157#31172 · In reply to: #31169 > Absolutely not the case. Take a look at C++, C#, even Python. The > "namespaces" implementation of those languages is mostly consistent > (even if Python doesn't call it that). Come on, python modules are not like C++ namespaces at all. For starters, AFAIK, python doesn't even have namespace declaration operator. And module loading and namespacing are combined. > You're not helping developers at all with this implementation. If you're How many developers did you ask, honestly? I had asked some, and they say it helps. Including on the list. You wanted to say I'm not helping some other developers? Well, too bad, there's no patch that can solve everybody's problems :) > working with a large library and have to import a lot of classes, the > way this works is nothing but a pain. We would be better off not using > namespaces at all, in this case. Thus, the problem has not been solved. Once more, you DO NOT have to import a lot of classes. Please do read what I write. You SHOULD NOT import classes in global space. Namespaces are NOT the way to bring all classes in global space, and it should not be done. > Also, for the implementation to be complete, Core Developers and > Extension Developers would need to namespace their classes / functions. Not necessarily. So far PHP core & PECL has been OK without it, there's not too many classes and the names are quite manageable, unless I miss something. > but you still need to offer developers *some* way of importing > everything out of a namespace. I absolutely will have upwards to close No, I don't need that. > to 25 - 30 classes in a single namespace. And sometimes more. To be able > to import them all is an absolute necessity for this implementation to No, it is not an absolute necessity, actually it's exactly the opposite. You don't want each module to inject 30 new names into global space, because you'll be running out of names very, very fast. > the fact that I may be using OTHER libraries as well that may be > namespaced. > > PEAR is a perfect example of this. Look at all the libraries that exist > there. I would absolutely love to just: > > import PEAR; > import PEAR::HTTP; > import PEAR::Image; Yeah, and not since you have generic PEAR exception class, HTTP exception class and image exception class, you've got three exception classes competing with system exception class for the name. Lovely. So now we get PEAR::PEAR_Exception to prevent that, right? So how it's better than just PEAR::Exception? > individual class that I need. And with all of the languages I mentioned > before, that is *exactly* how it works. Of course, we're back to the No, actually it doesn't. In python import - and that's what most use - doesn't bring names into global space. > namespacing of the PHP Core and Extensions. Which is really the main > blocker to any serious namespaces implementation, beyond what's > currently patched to HEAD today, correct? No, incorrect. The main blocker was that all other implementations were either inconsistent, hurting performance or too complex for PHP. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #31179 — pstradomski@gmail.com — 2007-07-23T09:40:55+00:00 URL: https://externals.io/message/31157#31179 · In reply to: #31172 Stanislav Malyshev wrote: > > […] > > Once more, you DO NOT have to import a lot of classes. Please do read > what I write. You SHOULD NOT import classes in global space. Namespaces > are NOT the way to bring all classes in global space, and it should not > be done. OK, so suppose I want to have four namespaces for my project: MyApp for some shared code, MyApp::Model MyApp::Controller MyApp::View Now in many places in my code in Model I'd use some ORM library - let's assume it's similar to python's SQLAlchemy. Now is there any way for me to have access **in Model namespace** to all classes from SQLAlchemy namespace without using import SQLAlchemy::Column import SQLAlchemy::Table import SQLAlchemy::Join import SQLAlchemy::ForeignKey import SQLAlchemy::Session import SQLAlchemy::Transaction and tens of other classes? I know your patch makes it possible to use fully qualified names everywhere. -- Paweł Stradomski --- ## #31185 — Brian Moon — 2007-07-23T14:25:19+00:00 URL: https://externals.io/message/31157#31185 · In reply to: #31179 > import SQLAlchemy::Column > import SQLAlchemy::Table > import SQLAlchemy::Join > import SQLAlchemy::ForeignKey > import SQLAlchemy::Session > import SQLAlchemy::Transaction Why use namespaces if you are going to do this? You are just bringing your classes into the global name space. The nice thing about namespaces IMO, is that I don't have to have a class named SQLAlchemy_Transaction. I can just have a class named Transaction in the SQLAlchemy namespace. I can then create a new object using $obj = new SQLAlchemy::Transaction. -- Brian Moon Senior Developer ------------------------------ http://dealnews.com/ It's good to be cheap =) --- ## #31188 — dz@bitxtender.com — 2007-07-23T14:42:04+00:00 URL: https://externals.io/message/31157#31188 · In reply to: #31185 Am 23.07.2007 um 16:25 schrieb Brian Moon: > > […] > > Why use namespaces if you are going to do this? You are just > bringing your classes into the global name space. The nice thing > about namespaces IMO, is that I don't have to have a class named > SQLAlchemy_Transaction. I can just have a class named Transaction > in the SQLAlchemy namespace. I can then create a new object using > $obj = new SQLAlchemy::Transaction. Oh yes, sure, that must be the main point about namespaces - I can use "::" instead of "_" as a delimiter! Yay! Come on, you can't be serious. David --- ## #31190 — pstradomski@gmail.com — 2007-07-23T14:43:22+00:00 URL: https://externals.io/message/31157#31190 · In reply to: #31185 Brian Moon wrote > > […] > > Why use namespaces if you are going to do this? You are just bringing > your classes into the global name space. The nice thing about > namespaces IMO, is that I don't have to have a class named > SQLAlchemy_Transaction. I can just have a class named Transaction in > the SQLAlchemy namespace. I can then create a new object using $obj = > new SQLAlchemy::Transaction. Because I just want those names directly available in one part of my application - the one which uses a lot of SQL. As far as I see this is not possibl with the proposed implementation - I can't do a local (file-scope or namespace-scope) import. All other languages I know that have namespaces (Java, python, C++) allow programmers to import other namespaces locally - usually for a single file. -- Paweł Stradomski --- ## #31192 — Derick Rethans — 2007-07-23T14:47:02+00:00 URL: https://externals.io/message/31157#31192 · In reply to: #31188 > Am 23.07.2007 um 16:25 schrieb Brian Moon: > > > […] > > Oh yes, sure, that must be the main point about namespaces - I can use "::" > instead of "_" as a delimiter! Yay! You forgot that you can also move the "prefix" in front of the class name to "namespace prefix!" > Come on, you can't be serious. I sort of agree, I don't see how the current implementation is really useful for anything. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org --- ## #31196 — Brian Moon — 2007-07-23T15:08:29+00:00 URL: https://externals.io/message/31157#31196 · In reply to: #31192 Derick Rethans wrote: > I sort of agree, I don't see how the current implementation is really > useful for anything. Well, for us, it would be useful for using 3rd party applications with our internally written code. We have mostly a functional (as in C not as in BASIC) environment. Recently we wanted to use Wordpress and MediaWiki for an internal project. We had to drudge through THEIR code and the error logs to find all the functions that conflicted with ones in our own code library. Now, if we had this namespaces implementation, we could namespace all of our internal code with a namespace of dealnews and ideally those projects would namespace their projects. This way there would be no conflicts in the global scope. Now, in Phorum, we did it the hard way and have hundreds of phorum_* functions. It makes for some really bad reading code with those huge function names. I guess what this comes down to is that these namespaces are better for project wide things and not so good at smaller parts. I agree that I would not want to work with 50 different namespaces with this solution. But, I would never work with 50 different namespaces as I don't find that type of organization useful. -- Brian Moon Senior Developer ------------------------------ http://dealnews.com/ It's good to be cheap =) --- ## #31201 — Stanislav Malyshev — 2007-07-23T15:59:54+00:00 URL: https://externals.io/message/31157#31201 · In reply to: #31190 > Because I just want those names directly available in one part of my > application - the one which uses a lot of SQL. As far as I see this is not If you want names to be part of global space - don't use namespaces. Namespaces are meant to take names OUT of global space. > All other languages I know that have namespaces (Java, python, C++) allow > programmers to import other namespaces locally - usually for a single file. Both Java and Python have much more rigid relations to files than PHP does - in Java, class is file, more or less, and package is directory, while in Python module is file and package is directory. Also, Java is a compiled language - meaning you have much more information in compile time than with PHP - all classes you use are to be known compile-time. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #31202 — nicobn@php.net — 2007-07-23T16:02:43+00:00 URL: https://externals.io/message/31157#31202 · In reply to: #31192 Despite all the comments made on this list by countless people, it's still Stanislav's way or the highway. I don't want to sound negative but come on... this is getting ridiculous. Stanislav, why don't you just tell everybody that you'll stop answering because the patch will stay AS IT IS over your dead body anyway ? I think you'll save us all some time. This discussion is endless and not productive. I can't speak for anybody here but I think a vote by all people who have commit access to php-src would clarify this issue once and for all so we can just move along. But that's just my 2 cents. > > > > > […] > your > > […] > IMO, is > > […] > just > > […] > then > > […] > "::" > > […] > > You forgot that you can also move the "prefix" in front of the class > name to "namespace prefix!" > > > […] > > I sort of agree, I don't see how the current implementation is really > useful for anything. > > regards, > Derick > -- > Derick Rethans > http://derickrethans.nl | http://ez.no | http://xdebug.org > > -- > > > -- Nicolas Bérard-Nault (nicobn@gmail.com) Étudiant D.E.C. Sciences, Lettres & Arts Cégep de Sherbrooke Homepage: http://nicobn.googlepages.com --- ## #31203 — Jeremy Privett — 2007-07-23T16:13:05+00:00 URL: https://externals.io/message/31157#31203 · In reply to: #31202 Yes, because that's ABSOLUTELY the way to respond to the community that has continued to support PHP. If that is what this discussion is going to degrade to, you're essentially saying "Please, gives us feedback but we're not listening." If this is the case, then I'll keep in mind and make sure it's known that bringing your issues and feedback to the PHP Devs is such a lovely waste of time and energy. Thanks. --- Jeremy Privett Software Developer Peak8 Solutions -----Original Message----- From: nicobn@gmail.com [mailto:nicobn@gmail.com] On Behalf Of Nicolas Bérard-Nault Sent: Monday, July 23, 2007 10:03 AM To: Derick Rethans Cc: David Zülke; PHP Internals Subject: Re: [PHP-DEV] Question about Namespace patch Despite all the comments made on this list by countless people, it's still Stanislav's way or the highway. I don't want to sound negative but come on... this is getting ridiculous. Stanislav, why don't you just tell everybody that you'll stop answering because the patch will stay AS IT IS over your dead body anyway ? I think you'll save us all some time. This discussion is endless and not productive. I can't speak for anybody here but I think a vote by all people who have commit access to php-src would clarify this issue once and for all so we can just move along. But that's just my 2 cents. > > > > > […] > your > > […] > IMO, is > > […] > just > > […] > then > > […] > "::" > > […] > > You forgot that you can also move the "prefix" in front of the class > name to "namespace prefix!" > > > […] > > I sort of agree, I don't see how the current implementation is really > useful for anything. > > regards, > Derick > -- > Derick Rethans > http://derickrethans.nl | http://ez.no | http://xdebug.org > > -- > > > -- Nicolas Bérard-Nault (nicobn@gmail.com) Étudiant D.E.C. Sciences, Lettres & Arts Cégep de Sherbrooke Homepage: http://nicobn.googlepages.com --- ## #31204 — David Coallier — 2007-07-23T16:18:44+00:00 URL: https://externals.io/message/31157#31204 · In reply to: #31203 > Yes, because that's ABSOLUTELY the way to respond to the community that has continued to support PHP. If that is what this discussion is going to degrade to, you're essentially saying "Please, gives us feedback but we're not listening." > > If this is the case, then I'll keep in mind and make sure it's known that bringing your issues and feedback to the PHP Devs is such a lovely waste of time and energy. > > Thanks. > > --- > Jeremy Privett > Software Developer > Peak8 Solutions > > -----Original Message----- > From: nicobn@gmail.com [mailto:nicobn@gmail.com] On Behalf Of Nicolas Bérard-Nault > Sent: Monday, July 23, 2007 10:03 AM > To: Derick Rethans > Cc: David Zülke; PHP Internals > Subject: Re: [PHP-DEV] Question about Namespace patch > > Despite all the comments made on this list by countless people, it's still > Stanislav's way or the highway. I don't want to sound negative but come > on... this is getting ridiculous. Stanislav, why don't you just tell > everybody that you'll stop answering because the patch will stay AS IT IS > over your dead body anyway ? I think you'll save us all some time. > > This discussion is endless and not productive. I can't speak for anybody > here but I think a vote by all people who have commit access to php-src > would clarify this issue once and for all so we can just move along. > > But that's just my 2 cents. > > > > […] > > > > -- > Nicolas Bérard-Nault (nicobn@gmail.com) > Étudiant D.E.C. Sciences, Lettres & Arts > Cégep de Sherbrooke > > Homepage: http://nicobn.googlepages.com > > -- > > > > Plus ca change, plus c'est pareil. -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 --- ## #31207 — Giedrius D — 2007-07-23T16:42:31+00:00 URL: https://externals.io/message/31157#31207 > David Zülke wrote: > > […] > > If all you are going to do is: > > > include "MyClass.php"; > import MyClass; > > ?> > > Then why use a namespace? I really don't see the point. Namespaces are > doing nothing for you in this case. It is not always in your power to decide if you need namespace or not. If you use some lib from Vendor1 there's a good chance that all lib is in Vendor1 namespace you want it or not. If you use that Vendor1 lib in one.php file a lot you clutter your code with Vendor1::A, Vendor1::B, Vendor1::C, etc. It is possible to rename Vendor1 to something shorter using import but you still have to prefix it. Now as import has effect only in file where it was used it would be nice to import all names from Vendor1 to the file one.php where it is heavy used and not to the ones that include one.php. So if the second.php file includes one.php global namespace is not cluttered with names from Vendor1 namespace. Only with names from one.php (if its names are not in some namespace by them selves.) This way second.php may include&import some lib from Vendor2 to accomplish its tasks without even worrying about libs used in one.php. That's why people sometimes want to import *all* names from namespace. Regards, Giedrius --- ## #31208 — Stanislav Malyshev — 2007-07-23T16:43:05+00:00 URL: https://externals.io/message/31157#31208 · In reply to: #31203 > Yes, because that's ABSOLUTELY the way to respond to the community > that has continued to support PHP. If that is what this discussion is > going to degrade to, you're essentially saying "Please, gives us > feedback but we're not listening." I responded - with arguments, explanation or reference to prior arguments - to every comment on the list. It is hardly "not listening". Maybe "not agreeing" - but nobody promised you to agree with everything you say here. It's not what "feedback" means. It means you will be listened to, your proposals would be weighted, discusses and seriously considered. That is what you are getting. I can not promise you immediate acceptance - and nobody would. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #31209 — Jeremy Privett — 2007-07-23T16:46:15+00:00 URL: https://externals.io/message/31157#31209 · In reply to: #31208 I wasn't referring to that. I know you've been responding to feedback. I was referring to Nicolas' suggested reply. --- Jeremy Privett Software Developer Peak8 Solutions -----Original Message----- From: Stanislav Malyshev [mailto:stas@zend.com] Sent: Monday, July 23, 2007 10:43 AM To: Jeremy Privett Cc: Nicolas Bérard-Nault; Derick Rethans; David Zülke; PHP Internals Subject: Re: [PHP-DEV] Question about Namespace patch > Yes, because that's ABSOLUTELY the way to respond to the community > that has continued to support PHP. If that is what this discussion is > going to degrade to, you're essentially saying "Please, gives us > feedback but we're not listening." I responded - with arguments, explanation or reference to prior arguments - to every comment on the list. It is hardly "not listening". Maybe "not agreeing" - but nobody promised you to agree with everything you say here. It's not what "feedback" means. It means you will be listened to, your proposals would be weighted, discusses and seriously considered. That is what you are getting. I can not promise you immediate acceptance - and nobody would. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #31210 — Stanislav Malyshev — 2007-07-23T16:50:20+00:00 URL: https://externals.io/message/31157#31210 · In reply to: #31202 > Despite all the comments made on this list by countless people, it's still > Stanislav's way or the highway. I don't want to sound negative but come No it isn't. If you failed to make convincing argument on one particular case, it in no way means that I am deaf to any argument at all - it just means your particular argument didn't convince me as of yet. > on... this is getting ridiculous. Stanislav, why don't you just tell > everybody that you'll stop answering because the patch will stay AS IT IS > over your dead body anyway ? I think you'll save us all some time. Because it's not true. We consulted with many people before this proposal, and we got positive feedbacks from yet more people after we made this proposal. Of course, there are people that have different opinion. But there's a difference between discussing opinions and dismissing other's opinion as illogical brain-dead stubbornness. I think I took a lot of effort in explaining my position - in many cases much more than opposing side did, when some people pretty much summed up with "your proposal is crap, it's not like Java, so I have no use for it". I will continue to put an effort in explaining. I however would not change my position just because somebody feels sore when his argument turns out not be as persuasive as he thought it would be. > This discussion is endless and not productive. I can't speak for anybody Make it productive. Propose something productive. By that I mean a consistent concept that will be superior to existing one. Or at least a consistent amendment to existing concept that would improve it. > here but I think a vote by all people who have commit access to php-src > would clarify this issue once and for all so we can just move along. I don't think these issues have to be decided by arithmetics. Of course, writing "+1" is much easier than spending a month on researching possible solution, considering all implications of each one and figuring out the optimal one - but I don't see any value in the former unless the latter was done. That doesn't mean expressing an opinion is to be discouraged - but there's more than sum of +1-es to make an informed decision that is going to influence PHP for years to come. I welcome everybody to make a contribution and discuss things - but please do not assume if you have an opinion everybody would agree. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #31211 — Derick Rethans — 2007-07-23T17:02:43+00:00 URL: https://externals.io/message/31157#31211 · In reply to: #31202 > Despite all the comments made on this list by countless people, it's still > Stanislav's way or the highway. I don't want to sound negative but come > on... this is getting ridiculous. Stanislav, why don't you just tell > everybody that you'll stop answering because the patch will stay AS IT IS > over your dead body anyway ? I think you'll save us all some time. There is no need to start attacking people so directly. Please keep it civilized. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org --- Next page: https://externals.io/message/31157.md?page=2