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 <la...@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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
