# Call it: allow reserved words in a class or not? - Thread: https://externals.io/message/41703 - Original archive: https://news-web.php.net/php.internals/41703 - Started by Stan Vassilev | FM on 2008-11-06T03:24:15+00:00 - Messages: 29 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/41703.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 --- ## #41703 — Stan Vassilev | FM — 2008-11-06T03:24:15+00:00 URL: https://externals.io/message/41703#41703 Hi, I just wanted a clarification on this. Currently many of us have class names such as: Zend_Validate_Interface Foo_Utils_Array ...and so on. This works fine as it's just a single T_STRING. As you know, with the new convention, the parser will not encounter `T_STRING` "Zend\Validate\Interface" but rather: `T_STRING` "Zend" `T_NS_SEPARATOR` "\" `T_STRING` "Validate" `T_NS_SEPARATOR` "\" `T_INTERFACE` <-- parse error I understand it's not trivial to fix this, but I wanted a clarification: is there a plan to do something about it, or it'll remain an invalid syntax by the time of release of 5.3. Regards, Stan Vassilev --- ## #41704 — Larry Garfield — 2008-11-06T03:54:29+00:00 URL: https://externals.io/message/41703#41704 · In reply to: #41703 On Wednesday 05 November 2008 9:24:15 pm Stan Vassilev | FM wrote: > Hi, > > I just wanted a clarification on this. Currently many of us have class > names such as: > > Zend_Validate_Interface > Foo_Utils_Array > > ...and so on. This works fine as it's just a single T_STRING. > > As you know, with the new convention, the parser will not encounter > `T_STRING` "Zend\Validate\Interface" but rather: > > `T_STRING` "Zend" > `T_NS_SEPARATOR` "\" > `T_STRING` "Validate" > `T_NS_SEPARATOR` "\" > `T_INTERFACE` <-- parse error > > I understand it's not trivial to fix this, but I wanted a clarification: is > there a plan to do something about it, or it'll remain an invalid syntax by > the time of release of 5.3. > > Regards, > Stan Vassilev Since I don't see why anyone would want to map the name that directly in the first place, I don't see anything here to fix. In that example, if you imported Zend\Validate\Interface you would then have to use it as: class Bob implements Interface { } Which is of course wrong on many levels. I'd file this under "if it breaks when you do that, don't do that". :-) -- Larry Garfield larry@garfieldtech.com --- ## #41707 — iammrdan@googlemail.com — 2008-11-06T09:35:18+00:00 URL: https://externals.io/message/41703#41707 · In reply to: #41704 What if you want to provide a set of helper/wrapper classes, appropriately namespaced, something along the lines of: MyFramework\Helpers\Array MyFramework\Helpers\Database MyFramework\Helpers\Session etc. If I want to use that naming convention, I don't want to have to name some of my classes differently just because PHP can't deal with it. It may not be trivial to fix, but to the end-developer, it's a trivial problem and it's something that should just work. Dan On Thu, Nov 6, 2008 at 3:54 AM, Larry Garfield wrote: > On Wednesday 05 November 2008 9:24:15 pm Stan Vassilev | FM wrote: > > […] > is > > […] > by > > […] > > Since I don't see why anyone would want to map the name that directly in > the > first place, I don't see anything here to fix. In that example, if you > imported Zend\Validate\Interface you would then have to use it as: > > class Bob implements Interface { } > > Which is of course wrong on many levels. I'd file this under "if it breaks > when you do that, don't do that". :-) > > -- > Larry Garfield > larry@garfieldtech.com --- ## #41708 — troels knak-nielsen — 2008-11-06T09:50:14+00:00 URL: https://externals.io/message/41703#41708 · In reply to: #41707 > What if you want to provide a set of helper/wrapper classes, appropriately > namespaced, something along the lines of: > MyFramework\Helpers\Array > MyFramework\Helpers\Database > MyFramework\Helpers\Session > etc. > > If I want to use that naming convention, I don't want to have to name some > of my classes differently just because PHP can't deal with it. It may not be > trivial to fix, but to the end-developer, it's a trivial problem and it's > something that should just work. I think the point is the same as with Zend_Validate_Interface ; While MyFramework\Helpers is a fair namespace, Array is a bad classname. You should use something like MyFramework\Helpers\ArrayHelper FWIW Zend_Validate_Interface looks odd to me today already, for that reason exactly. I read two namespaces and a classname, and that classname doesn't make much sense. -- troels --- ## #41709 — iammrdan@googlemail.com — 2008-11-06T10:03:46+00:00 URL: https://externals.io/message/41703#41709 · In reply to: #41708 Isn't the ability to do that one of the biggest reasons for having namespaces? To avoid having to fill your class names with junk. The examples are namespaced appropriately, they tell the developer that it's a Helper for Arrays in the MyFramework framework. I shouldn't need to suffix the class name with 'Helper' to reconfirm that, just because the PHP engine doesn't like it. Dan On Thu, Nov 6, 2008 at 9:50 AM, troels knak-nielsen wrote: > > > […] > appropriately > > […] > some > > […] > be > > […] > > I think the point is the same as with Zend_Validate_Interface ; While > MyFramework\Helpers is a fair namespace, Array is a bad classname. You > should use something like MyFramework\Helpers\ArrayHelper > > FWIW Zend_Validate_Interface looks odd to me today already, for that > reason exactly. I read two namespaces and a classname, and that > classname doesn't make much sense. > > -- > troels --- ## #41710 — Robert Lemke — 2008-11-06T10:12:52+00:00 URL: https://externals.io/message/41703#41710 · In reply to: #41709 Hi Dan, Am 06.11.2008 um 11:03 schrieb Dan: > Isn't the ability to do that one of the biggest reasons for having > namespaces? To avoid having to fill your class names with junk. > The examples are namespaced appropriately, they tell the developer > that it's > a Helper for Arrays in the MyFramework framework. I shouldn't need > to suffix > the class name with 'Helper' to reconfirm that, just because the PHP > engine > doesn't like it. we also had lots of classes like "F3\MVC\Controller\Interface", "F3\MVC\Controller\Default" etc. ("default" is also a reserved word unfortunately). So we had to rename all these classes and interfaces. After doing that though, I think it's much better this way. IMO a class name should speak for itself even without namespaces, the namespaces should only put into a certain context: "DefaultController" is a default controller. "F3\FooPackage\Controller\DefaultController" is the default controller of the FooPackage, "F3\BarPackage\Controller\DefaultController" is the default controller of the BarPackage etc. So, even though I was annoyed having to refactor so much code, I am now happy with the results. Cheers, robert --- ## #41711 — Steph Fox — 2008-11-06T11:00:59+00:00 URL: https://externals.io/message/41703#41711 · In reply to: #41709 > Isn't the ability to do that one of the biggest reasons for having > namespaces? To avoid having to fill your class names with junk. > The examples are namespaced appropriately, they tell the developer that > it's > a Helper for Arrays in the MyFramework framework. I shouldn't need to > suffix > the class name with 'Helper' to reconfirm that, just because the PHP > engine > doesn't like it. This thread really should be re-titled to "allow reserved words as a classname or not". Then perhaps the only logical response to the question would be so obvious that there would be no thread... oo-er... - Steph --- ## #41712 — Alexey Zakhlestin — 2008-11-06T11:38:33+00:00 URL: https://externals.io/message/41703#41712 · In reply to: #41711 > This thread really should be re-titled to "allow reserved words as a > classname or not". Then perhaps the only logical response to the question > would be so obvious that there would be no thread... oo-er... +1 my favourite example: "class class extends namespace implements interface" -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ --- ## #41713 — Ben Davies — 2008-11-06T11:43:03+00:00 URL: https://externals.io/message/41703#41713 · In reply to: #41711 > Isn't the ability to do that one of the biggest reasons for having > namespaces? To avoid having to fill your class names with junk. > The examples are namespaced appropriately, they tell the developer that > it's > a Helper for Arrays in the MyFramework framework. I shouldn't need to > suffix > the class name with 'Helper' to reconfirm that, just because the PHP > engine > doesn't like it. "This thread really should be re-titled to "allow reserved words as a classname or not". Then perhaps the only logical response to the question would be so obvious that there would be no thread... oo-er..." I think you might be deliberately missing Dan's point here: array is a reserved word because it is not namespaced. If the PHP native function array() was namespaced to PHPCore\array() then Dan could create a class or function called array under his own namespace. This is exactly what namespacing affords us. array() is only a reserved word because it is not a directly accessable native datatype. If array() was an object Array, this wouldn't be a problem. This namespaces issues highlights the very fundamental issues with PHP, and glib, childish responses like yours only serve to score points. Grow up and join the conversation. Ben Davies | Lead Developer | Stickyeyes 6th Floor, West One, Wellington Street, Leeds, LS1 1BA Email: ben@stickyeyes.com 0113 391 2929 | | Fax 0113 391 2939   This e-mail may contain information that is privileged, confidential or otherwise protected from disclosure. It must not be used by, or its contents copied or disclosed to persons other than the intended recipient. Any liability (in negligence or otherwise) arising from any third party acting, or refraining from acting, on any information contained in this e-mail is excluded. The views expressed may not be official company policy, but instead, the personal views of the originator. If you have received this e-mail in error please notify the sender and delete the e-mail. -----Original Message----- From: Steph Fox [mailto:steph@php.net] Sent: 06 November 2008 11:01 To: Dan; troels knak-nielsen Cc: Larry Garfield; internals@lists.php.net; ben@stickyeyes.com Subject: Re: [PHP-DEV] Call it: allow reserved words in a class or not? > Isn't the ability to do that one of the biggest reasons for having > namespaces? To avoid having to fill your class names with junk. > The examples are namespaced appropriately, they tell the developer that > it's > a Helper for Arrays in the MyFramework framework. I shouldn't need to > suffix > the class name with 'Helper' to reconfirm that, just because the PHP > engine > doesn't like it. This thread really should be re-titled to "allow reserved words as a classname or not". Then perhaps the only logical response to the question would be so obvious that there would be no thread... oo-er... - Steph --- ## #41714 — iammrdan@googlemail.com — 2008-11-06T11:53:30+00:00 URL: https://externals.io/message/41703#41714 · In reply to: #41713 Quite. It does appear as though, as a group, that you're struggling with the entire concept of namespaces. As demonstrated by this discussion, the resolution issues, the separator farce, and so on. It may be due to weaknesses in the PHP engine as a whole, I don't know... but it strikes me that most of these issues should be trivial ones, or ones that could be eliminated simply by approaching language design decisions with some common sense. In .NET, I can stick an Array class into my own namespace, extending the System.Array type if I want to and use it in my code without issue. Why can I not do that here? Is it simply that you're so worried about backwards compatibility that you feel that you can't make the necessary changes to the language to implement something fully? Dan > > […] > > "This thread really should be re-titled to "allow reserved words as a > classname or not". Then perhaps the only logical response to the question > would be so obvious that there would be no thread... oo-er..." > > I think you might be deliberately missing Dan's point here: array is a > reserved word because it is not namespaced. If the PHP native function > array() was namespaced to PHPCore\array() then Dan could create a class or > function called array under his own namespace. This is exactly what > namespacing affords us. > > array() is only a reserved word because it is not a directly accessable > native datatype. If array() was an object Array, this wouldn't be a > problem. > > This namespaces issues highlights the very fundamental issues with PHP, and > glib, childish responses like yours only serve to score points. > > Grow up and join the conversation. > > > Ben Davies | Lead Developer | Stickyeyes > 6th Floor, > West One, > Wellington Street, > Leeds, LS1 1BA > Email: ben@stickyeyes.com > 0113 391 2929 | | Fax 0113 391 2939 > > This e-mail may contain information that is privileged, confidential or > otherwise protected from disclosure. It must not be used by, or its > contents > copied or disclosed to persons other than the intended recipient. Any > liability (in negligence or otherwise) arising from any third party acting, > or refraining from acting, on any information contained in this e-mail is > excluded. The views expressed may not be official company policy, but > instead, the personal views of the originator. If you have received this > e-mail in error please notify the sender and delete the e-mail. > > > > -----Original Message----- > From: Steph Fox [mailto:steph@php.net] > Sent: 06 November 2008 11:01 > To: Dan; troels knak-nielsen > Cc: Larry Garfield; internals@lists.php.net; ben@stickyeyes.com > Subject: Re: [PHP-DEV] Call it: allow reserved words in a class or not? > > > […] > > This thread really should be re-titled to "allow reserved words as a > classname or not". Then perhaps the only logical response to the question > would be so obvious that there would be no thread... oo-er... > > - Steph --- ## #41715 — Steph Fox — 2008-11-06T11:58:36+00:00 URL: https://externals.io/message/41703#41715 · In reply to: #41713 This namespaces issues highlights the very fundamental issues with PHP, and glib, childish responses like yours only serve to score points. === The 'very fundamental issue' here is that you're expecting namespaces to allow things that are not legal in non-namespaced PHP code. The entire thrust of the internals discussion preceding this has been that preserving similar resolution rules in namespaced PHP code to those that already exist, will avoid potential confusion. And don't tell me to 'grow up' or I'll set my grandchildren on you ;) - Steph --- ## #41716 — Steph Fox — 2008-11-06T12:03:39+00:00 URL: https://externals.io/message/41703#41716 · In reply to: #41714 > In .NET, I can stick an Array class into my own namespace, extending the > System.Array type if I want to and use it in my code without issue. Why > can > I not do that here? Is it simply that you're so worried about backwards > compatibility that you feel that you can't make the necessary changes to > the > language to implement something fully? .NET is an object oriented language. It has something called System.Array. PHP is a hybrid language. It does not and hopefully never will have something called System.Array. It's like the difference between English and Esperanto... and you're telling us 'cough' should rhyme with 'cow' because that's how Esperanto would have it. But English is so much easier to learn, if more difficult to master, that it's become the lingua franca for the 'net. - Steph > > Dan > > > On Thu, Nov 6, 2008 at 11:43 AM, Ben Davies > wrote: > > > […] --- ## #41717 — Ben Davies — 2008-11-06T12:07:48+00:00 URL: https://externals.io/message/41703#41717 · In reply to: #41715 Ben Davies | Lead Developer | Stickyeyes -----Original Message----- From: Steph Fox [mailto:steph@php.net] Sent: 06 November 2008 11:59 To: Ben Davies; 'Dan'; 'troels knak-nielsen' Cc: 'Larry Garfield'; internals@lists.php.net Subject: Re: [PHP-DEV] Call it: allow reserved words in a class or not? This namespaces issues highlights the very fundamental issues with PHP, and glib, childish responses like yours only serve to score points. === The 'very fundamental issue' here is that you're expecting namespaces to allow things that are not legal in non-namespaced PHP code. The entire thrust of the internals discussion preceding this has been that preserving similar resolution rules in namespaced PHP code to those that already exist, will avoid potential confusion. And don't tell me to 'grow up' or I'll set my grandchildren on you ;) - Steph --- ## #41719 — iammrdan@googlemail.com — 2008-11-06T12:15:36+00:00 URL: https://externals.io/message/41703#41719 · In reply to: #41716 Okay, I'm not going to sit and argue it... but to anyone looking at these issues from outside the PHP internals world (like I am), that argument is worthy of ridicule. PHP may be a hybrid language, but the fact is you're implementing object oriented functionality, and as such should be implementing it in a way that follows de-facto standards in object oriented language design. I should be able to overload your internal array object, and yes, arraysshould be objects. Javascript would be a prime example of a non-standard object oriented approach, and yet that still manages to support the basics in a way that make sense. Dan > In .NET, I can stick an Array class into my own namespace, extending the > > […] > > .NET is an object oriented language. It has something called System.Array. > > PHP is a hybrid language. It does not and hopefully never will have > something called System.Array. > > It's like the difference between English and Esperanto... and you're > telling us 'cough' should rhyme with 'cow' because that's how Esperanto > would have it. But English is so much easier to learn, if more difficult to > master, that it's become the lingua franca for the 'net. > > - Steph > > > > > > […] --- ## #41720 — Steph Fox — 2008-11-06T12:33:59+00:00 URL: https://externals.io/message/41703#41720 · In reply to: #41719 Dan, > PHP may be a hybrid language, but the fact is you're implementing object > oriented functionality, and as such should be implementing it in a way > that > follows de-facto standards in object oriented language design. I should be > able to overload your internal array object, and yes, arraysshould be > objects. I'm really confused as to why you'd want to overload something that doesn't exist. Can't we just deal with reality here? Several million PHP scripts written over the last decade will still able to run without change under PHP 5.3. Several PHP developers are not OO programmers and some - maybe even most - never will be. Don't you think that suddenly turning arrays into objects might cause just the teeniest bit of a problem here? > Javascript would be a prime example of a non-standard object oriented > approach, and yet that still manages to support the basics in a way that > make sense. Great, so drop PHP and go use Javascript. Oh wait - you can't. Because *it wasn't designed do the same job*. - Steph --- ## #41721 — Mikko Koppanen — 2008-11-06T12:35:45+00:00 URL: https://externals.io/message/41703#41721 · In reply to: #41719 > Okay, I'm not going to sit and argue it... but to anyone looking at these > issues from outside the PHP internals world (like I am), that argument is > worthy of ridicule. What argument? Due to top-posting you're kind of killing the ability to follow the thread. > PHP may be a hybrid language, but the fact is you're implementing object > oriented functionality, and as such should be implementing it in a way that > follows de-facto standards in object oriented language design. I should be > able to overload your internal array object, and yes, arraysshould be > objects. Wouldn't this mean that also primitive types such as integer and string should be objects? Doing something like this would break about all the code out there without a major gain. One of the strenghts of PHP is that it balances well between procedural and object oriented approaches. There is ArrayObject, ArrayAccess etc for people who wish to use OO and array for the people who don't. > Javascript would be a prime example of a non-standard object oriented > approach, and yet that still manages to support the basics in a way that > make sense. > I think you are missing a point here. PHP is not Javascript or .NET. -- Mikko Koppanen --- ## #41724 — Gregory Beaver — 2008-11-06T14:50:12+00:00 URL: https://externals.io/message/41703#41724 · In reply to: #41714 Dan wrote: > Quite. > > It does appear as though, as a group, that you're struggling with the entire > concept of namespaces. As demonstrated by this discussion, the resolution > issues, the separator farce, and so on. > > It may be due to weaknesses in the PHP engine as a whole, I don't know... > but it strikes me that most of these issues should be trivial ones, or ones > that could be eliminated simply by approaching language design decisions > with some common sense. > > In .NET, I can stick an Array class into my own namespace, extending the > System.Array type if I want to and use it in my code without issue. Why can > I not do that here? Is it simply that you're so worried about backwards > compatibility that you feel that you can't make the necessary changes to the > language to implement something fully? Hi Dan, OSS = show us a working patch and we'll consider it. Do this before saying the issues "should be trivial ones." Not too long ago I spent a significant amount of time trying to make it possible to use a few reserved words as method names or function names, and the result was a patch that made the parser and lexer significantly more complex, with lots of bugs that were very difficult to fix, and some edge cases where parsing simply failed. As an example of why your suggestion is not logically possible to implement, what should the following code print, 1 or 2? No human can tell whether you mean to call the namespace\namespace\test() function, or simply to call the test() function from the current namespace. Do you really expect a machine to do any better? Please spend at least 2 minutes carefully trying to think of an edge case before lamenting any feature in the language, otherwise your posts kill your credibility on the list and are frankly nothing other than annoying noise. Greg --- ## #41728 — Matthew Schiros — 2008-11-06T16:05:37+00:00 URL: https://externals.io/message/41703#41728 · In reply to: #41719 > PHP may be a hybrid language, but the fact is you're implementing object > oriented functionality, and as such should be implementing it in a way that > follows de-facto standards in object oriented language design. I should be > able to overload your internal array object, and yes, arraysshould be > objects. Why should _all_ arrays be objects? Because that's the way Java and .NET do it? Should PHP then take it one step further and adopt the OO model where all primitive data types become objects as well, so you can overload an Int, Char, or Float? That seems to be the logical extension of your argument, and not only is it incompatible with PHP's hybrid nature, it'd be a downside for adoption of the language as a whole. One of the reasons PHP has the penetration that it does is that it has a very low barrier to entry, you don't _need_ to be an OO programmer, or even know what object oriented programming is, to write effective, efficient PHP scripts and applications that solve a task for you. If you _want_ to use an Array object, there's one available in the SPL, ArrayObject. Breaking everyone's code in the name of blind obedience to principles of object oriented programming seems silly, to say the least, especially when there's an option already available within PHP that allows you to use OO-Arrays. Yes, it will be mildly irritating for people who have classes named things like MyHelperInterface, who then break it out into My\Helper\Interface . Of course, they could solve those problems by breaking it out into My\HelperInterface or My\Helpers\HelperInterface (or InterfaceHelper), and to say that that minor renaming of a class invalidates the usefulness of PHP namespaces is like saying that removing the ability to have a function named public() post-PHP4 (or whenever public became a reserved word) invalidates PHP's OO usefulness. No solution to namespacing will be all things to all people. Lots of people don't like the use of \ as opposed to :: (I'm one of them, although I am convinced by the arguments the \ people have put forward that it's necessary), but do their objections render PHP namespacing useless? Does the lack of multiple inheritance support render PHP's OO useless? No, of course not. It's all a compromise between (sometimes) competing desires to develop the language in a way that is most useful to most people. Matt > > > > […] > -- Matt Schiros --- ## #41729 — Stan Vassilev | FM — 2008-11-06T16:36:12+00:00 URL: https://externals.io/message/41703#41729 · In reply to: #41728 Hi, Watching my thread devolve into a blamefest wasn't the intention. I just wanted a clear answer if something's done about it or not. To everyone participating in the thread: guys it's NOT trivial in the current situation. To the parser, a separate string matching a keyword is the token keyword. Reverting this or making it context sensitive is not trivial by any means. Still though: it IS possible, you'll find plenty of examples of context-specific keywords in other languages (including C# which was quoted here). Oh and btw, greg, in your example: you should print "1". There's one trivial solution: make the keywords and class names case-sensitive. Then classes "If", "Array", "Interface" will never class with the all-lowercase keywords. I have to say, we sorely do need consistency on that front as well, and since vars are already case sensitive, making it all case sensitive is one way to go forward. Why is this a problem at all? Well as people said, in .NET words like "array" are not a reserrved word. Even more, if I have Foo.Utils.FooUtils, that's some redundancy I can easily avoid in .NET by "using Foo.Utils.*". In PHP, we can't do star-imports since the parser doesn't know what's there to import at runtime. So we can't easily avoid the redundancy, unless we manually import the classes we want to use, one by one. So that's one more hassle which make redundant names a pain. Regards, Stan Vassilev --- ## #41730 — Josh Davis — 2008-11-06T17:08:07+00:00 URL: https://externals.io/message/41703#41730 · In reply to: #41729 2008/11/6 Stan Vassilev | FM : > > There's one trivial solution: make the keywords and class names > case-sensitive. Then classes "If", "Array", "Interface" will never class > with the all-lowercase keywords. As much as I'd love to see more case-sensitivity, I'm afraid it would break quite a lot of existing apps, according to Google Code. http://www.google.com/codesearch?q=lang%3Aphp+%3D%5Cs%2AArray -JD --- ## #41734 — Stanislav Malyshev — 2008-11-06T18:14:10+00:00 URL: https://externals.io/message/41703#41734 · In reply to: #41703 Hi! > As you know, with the new convention, the parser will not encounter `T_STRING` "Zend\Validate\Interface" but rather: With namespaces, class name would not be Zend\Validate\Interface. Having namespaces, it would make much more sense to make last component a descriptive name, so you won't have code like this: if($object instanceof Interface) { // wtf am I checking here? ... As for how exactly that descriptive name should look - I guess each framework's developers that plan to support namespaces think about it hard right now. I know ZF developers do :) -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #41736 — Stan Vassilev | FM — 2008-11-06T18:33:33+00:00 URL: https://externals.io/message/41703#41736 · In reply to: #41734 > Hi! > > > […] > > With namespaces, class name would not be Zend\Validate\Interface. Having > namespaces, it would make much more sense to make last component a > descriptive name, so you won't have code like this: > > if($object instanceof Interface) { // wtf am I checking here? > ... > > As for how exactly that descriptive name should look - I guess each > framework's developers that plan to support namespaces think about it hard > right now. I know ZF developers do :) Hi, Fully agreed. Though since we (PHP users) will all be using namespaces together, it makes much more sense that we have a paradigm, recommendation for namespace usage that all frameworks will follow. Maybe the ZF, Agavi, CI, CakePHP etc. authors should get together and craft a single recommendation list for people to use. It's not just a matter of consistency, it's a matter of makming the language work well with the recommended scenario and use patterns of namespaces. Two things are obvious: 1) What worked with underscores won't work with namespaces. 2) What scenario above with "instanceof Interface" isn't very likely. Why? Well imagine you want to use 5 classes in namespace foo\bar, called A, B, C, D, E (ex. foo\bar\A). In most any language with packaging system, to flatten the space you simply do this: use foo\bar\*; $a = new A(); $b = new B(); ... In PHP, due to lack of packaging system and knowledge of the user resources at parse time, instead we're painfully explicit: use foo\bar\A; use foo\bar\B; use foo\bar\C; use foo\bar\D; use foo\bar\E; $a = new A(); $b = new B(); Which makes this usage pattern with aliases much more likely to see: use foo\bar as fb; $a = new fb\A(); $b = new fb\B(); So your example above would rather be: use Zend\Validate as ZV; ... instanceof ZV\Interface; And this is why it's worth it to arrive at a single list of recommendations for namespace usage, and see what works there and what might not work, and tweak the language for it. Regards, Stan Vassilev --- ## #41747 — Josh Thompson — 2008-11-07T04:19:27+00:00 URL: https://externals.io/message/41703#41747 · In reply to: #41736 Stan Vassilev | FM wrote: > use foo\bar\*; > > $a = new A(); > $b = new B(); > ... I may be asking this question out of ignorance, but here goes: What is the difference between the following snippets? // global.php use \foo\bar\*; $a = new A(); $b = new B(); // namespaced.php namespace \foo\bar; $a = new A(); $b = new B(); I don't understand why in the namespaced example no one seems to have a problem with new A() meaning new \foo\bar\A(), but we can't use the * wildcard to do the same thing? -- Joshua Thompson Mechanical Engineer/Software Developer http://www.schmalls.com --- ## #41749 — johannes@php.net — 2008-11-07T07:27:51+00:00 URL: https://externals.io/message/41703#41749 · In reply to: #41747 > I don't understand why in the namespaced example no one seems to have a > problem with new A() meaning new \foo\bar\A(), but we can't use the * > wildcard to do the same thing? Since we don't reliable know all possible classes, think about _-autoloading classes, which means we'd have to do more work during execution, which can be a slowdown. johannes --- ## #41756 — Karsten Dambekalns — 2008-11-07T09:42:43+00:00 URL: https://externals.io/message/41703#41756 · In reply to: #41711 Hi. Steph Fox wrote: > This thread really should be re-titled to "allow reserved words as a > classname or not". Then perhaps the only logical response to the > question would be so obvious that there would be no thread... oo-er... Right, the subject indicates a different question that what seems to be discusssed here. The way I understood it was about allowing *methods* named "clone" in a class. That would come in handy for me, porting interfaces from Java to PHP. Currently I have to go back to "klone" to make it legal. Regards, Karsten --- Next page: https://externals.io/message/41703.md?page=2