Re: Questioning the future of PHP

We still don't have a way to auto load non class entities. Other than that, PSR-0 does solve the majority of autoload use cases. Cheers, David Sent from my iPhone On 04/02/2013, at 5:18 PM, Larry Garfield <larry@garfieldtech.com> wrote: > On 02/03/2013 08:51 PM, Matt Wilson wrote: >> Hello all. I'd like to start by saying that I am by no means an expert on the subject >> at hand, and my knowledge is limited to pretty much basic C/C++.. I have done little more than patch >> and write ad hoc extensions for PHP in the past. I'm not looking to criticize so much, as >> I'm just interested in an honest discussion, for my own sake and understanding. >> >> Many years ago I was on this internals list lamenting that PHP lacked namespaces. I was >> passionate in my conviction that it couldn't be a true language if it lacked them. But it >> wasn't until they were finally being considered that I realized the one weakness in PHP that >> prevented a proper namespace system. The autoload problem. Since PHP lacks an inherent style of code >> importation, it is a decision largely left up to the developer. This of course causes an order of >> precedence problem. >> >> Now, I won't lie, some of my beef with namespaces as they stand is the \. What can I >> say, I like a certain feng shui in my code. I understand the technical limitations (or at least >> think I do) and the problem of ambiguity with other operators, however I feel more effort might have >> been made. >> >> If I were to pull some examples out of my ass, and feel free to rebuke me if I'm >> missing something obvious, >> >> [namespace foo.bar] >> >> new [foo.bar.SomeClass]() >> >> Would that be so hard to distinguish in the parser? If it is, I'd be grateful to know >> why. > > Maybe it would work, maybe it wouldn't, I don't know. But that ship sailed a long > time ago and it cannot be changed now without breaking a few million lines of code. Please let that > issue die. > >> Touching back on what I mentioned earlier about PHP not having an inherent way to load >> files, and in daily use it's somewhat arbitrary. I share the philosophy that the programmer >> should tell the code what to do, and not the other way around; however, I think some enforced >> structure can be good. This is something of a wet dream of mine and one I highly doubt will come >> true, but to get rid of __autoload (or at least supplant it with a default loader) would be a dream. >> I think it's something that PHP needs, to complete some one of advances its made in recent >> years. >> >> Thanks, >> Matt > > "The autoload problem" has already been solved by PSR-0. If you're not using it > yet, you should. All the cool kids are. > > http://www.php-fig.org/ > > If you're using Composer to manage dependencies, it includes a fully capable PSR-0 > autoloader that "just works", as well as a classmap-based option. If you're not > using it yet, you should. All the cool kids are. > > http://getcomposer.org/ > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >