[PHP-DEV] Namespace and autoloader Re: [PHP-DEV] Questioning the future of PHP
Would that be so hard to distinguish in the parser? If it is, I'd be grateful to know why. We already have it in now. Changing it for cosmetics would break existing code, and I have not yet understood for what benefit? 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. PHP's autoloader works on classes. Purely functional code should not have a problem with an include hierarchy, whereas OO-code can either use the default autoloader or use a userland version (I use Horde_Autoloader, but it's not the first and not the only implementation which allows class naming beyond PSR-0 standards. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: l...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Questioning the future of PHP
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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Questioning the future of PHP
This is something of a wet dream of mine TMI, my friend. TMI. Anyway... I think your Subject is unnecessarily trolly even if the substance of your post isn't. So maybe you could re-post with a WAS: Questioning... to avoid p'ing off the dev team? If I'm understanding your statement of The autoload problem correctly, the language-default spl_autoload function indeed allows you to install a package safely -- in an environment that you know has not completely overridden the default autoloader. If you want to make sure the default is called for your directory structure, then you can make sure to tell the people using your package to put the default spl_autoload in their autoloader chain. Can you explain how this departs from your vision? I don't think what you want is another default autoloader, but a way of ensuring the system default is called once your package is physically installed on a system. Unfortunately, there would always be file I/O overhead if it were to be called even if the PHP install has nothing in the default file layout. You could argue that the default spl_autoload should run unless deliberately turned off (never mind BC for the moment), but then it would just become a popular best practice to turn it off and you're back at the same place. -- Sandy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Questioning the future of PHP
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
Re: [PHP-DEV] 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 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
