31–40 of 349 posts
My problem with PHP is that it solves the issue of code reuse the wrong way round. In other languages, you can import code like this: import mail as mailer The external code ("mail") does not have to make assumptions how it will be called when it is used. In PHP, it is the other way round. Every piece of code needs to try avoiding namespace conflicts by prefixing the code with something like this: namespace Illuminat…
Earlier quoted context omitted.
You can `use Illuminate\Mail as Mailer` if you want
That is not what I mean. It would not prevent a clash with another "Illuminate" namespace. The problem is that the developer of "Illuminate\Mail" had to introduce the "Illuminate" namespace and hope nobody else uses it. Additionally it makes the code more complex. Every file needs to carry this "namespace ...." line now.
My problem with PHP is that it solves the issue of code reuse the wrong way round. In other languages, you can import code like this: import mail as mailer The external code ("mail") does not have to make assumptions how it will be called when it is used. In PHP, it is the other way round. Every piece of code needs to try avoiding namespace conflicts by prefixing the code with something like this: namespace Illuminat…
The way I see it is that you alias the import mail as mailer. You hope there are no other libraries called mail in your import path. PHP fixes that by requiring all libraries called mail to be dependent on their own namespace so that there will be no collisions. I think that neither do make assumptions on how the code is called when used, only one is preventing name collisions.
You hope there are no other libraries
called mail in your import path.
I can put those two mail modules in:
stuff/mail
tools/mail
from stuff import mail as mail1
from tools import mail as mail2
But, really, I suggest using other tools. We have nicer tools now.
I totally expected it to be a troll site. It's actually sensible advice. But, really, I suggest using other tools. We have nicer tools now.
Earlier quoted context omitted.
That is not what I mean. It would not prevent a clash with another "Illuminate" namespace. The problem is that the developer of "Illuminate\Mail" had to introduce the "Illuminate" namespace and hope nobody else uses it. Additionally it makes the code more complex. Every file needs to carry this "namespace ...." line now.
You can hope all you want but you won't be able to submit any duplicated namespace to Packagist.
The consequence you mention is that one depends more and more on tooling and services.
Earlier quoted context omitted.
PHP share-nothing architecture is awesome. It's amazingly simple and it scales to arbitrary size.
Complicated frameworks means the “shared nothing architecture” is unusable and you have to use fcgi/fpm to get acceptable performances out of your website. At which point there’s little difference from .
I totally expected it to be a troll site. It's actually sensible advice. But, really, I suggest using other tools. We have nicer tools now.
But what's the point? The beauty of perl scripts, and later php templates, was in their BASIC-like simplicity. They were not secure or structured in any way, but very accessible. Once you add these frameworks, you realize you could have started with Python or Java in the first place and get more mature infrastructure and better language along the way.
PHP share-nothing architecture is awesome. It's amazingly simple and it scales to arbitrary size.
Earlier quoted context omitted.
That is not what I mean. It would not prevent a clash with another "Illuminate" namespace. The problem is that the developer of "Illuminate\Mail" had to introduce the "Illuminate" namespace and hope nobody else uses it. Additionally it makes the code more complex. Every file needs to carry this "namespace ...." line now.
You can hope all you want but you won't be able to submit any duplicated namespace to Packagist.