Live data from Hacker News

PHP – The Right Way

phptherightway.com

61–70 of 349 posts

Re: PHP – The Right Way

#61
post #49
post #36

Earlier quoted context omitted.

That is another consequence I don't like about the quirky namespace approach. It collects more and more problems like a ball of dust that gets bigger and bigger. The consequence you mention is that one depends more and more on tooling and services.

Did you actually get these issues in a real use case? I've been developing PHP software for +15 years and I never had this namespace dilema.

But you suffer the indirections caused by the fat stack that is needed to deal with the missing import system.

In Python, "import" actually imports the code.

In PHP, the "use" statement you see everywhere does not. It only works because the code has already "magically" been imported.

Usually by composer. Thats why there are tens of thousands of hits for "clear composer cache" on Google. To just point out one issue with the dependecy on a fat stack to deal with a missing import system.

Re: PHP – The Right Way

#62
post #33

Earlier quoted context omitted.

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. Let's take Python for example. With Python, I am in control of the import path. I can put those two mail modules in: stuff/mail tools/mail And then use them like this: from stuff import mail as mail1 from tools import mail as mail2 I don't have to hope for anything.

That example would become `use Stuff\Mail as Mail1` and `use Tools\Mail as Mail2` in PHP. What's the difference?

Re: PHP – The Right Way

#64
Actually, that make me remember statements of Linus Torvalds on Git at Google Tech Talk Conference:

But I did end up using CVS for seven years at a commercial company and I hated it with a passion. When I say I hate CVS with a passion, I have to also say that if there are any SVN users in Subversion, users in the audience, you might want to leave because my hatred of CVS has meant that I see Subversion as being the most pointless project ever started, because the slogan for Subversion for a while was, CVS done right or something like that.

And if you start with that kind of slogan, there’s nowhere you can go. It’s like — there is no way to do CVS right. So that’s the negative kind of credit.

https://singjupost.com/linus-torvalds-on-git-at-google-tech-...

Re: PHP – The Right Way

#65
post #34

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, really, I suggest using other tools. We have nicer tools now. Citation needed. For folks not wishing to switch frameworks and tooling every year, you can get a lot done with PHP.

> Citation needed.

I really like Django as an opinionated framework. I have also used Flask, Falcon, and FastAPI, all with good results in their own niche. I also like Play and Scala and Spring Boot with Java.

> For folks not wishing to switch frameworks and tooling every year, you can get a lot done with PHP.

You can also get a lot done with wood and nails, but that doesn't mean it's the best tool for all kind of jobs.

Re: PHP – The Right Way

#66
post #11

Earlier quoted context omitted.

PHP share-nothing architecture is awesome. It's amazingly simple and it scales to arbitrary size.

PHP did not invent CGI and the whole selling point of mod_php was "share-something" architecture.

For the PHP-side application developer, PHP is in 99% of use cases shared-nothing no matter the hosting environment - CGI, FCGI, FPM, mod_php. The exceptions are persistent socket (database) related, obviously you don't have these in a CGI environment.

The mod_php "share-something" question was always more relevant for ops people.

Re: PHP – The Right Way

#67
post #60
post #34

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.

I, for one, would chose PHP8 over Javascript all day, every day. And there seem to be millions like me.

Well... I wouldn't recommend JavaScript. TypeScript is much nicer and removes a lot of the JS pitfalls.

Re: PHP – The Right Way

#69
post #33

Earlier quoted context omitted.

You hope there are no other libraries called mail in your import path. Let's take Python for example. With Python, I am in control of the import path. I can put those two mail modules in: stuff/mail tools/mail And then use them like this: from stuff import mail as mail1 from tools import mail as mail2 I don't have to hope for anything.

That example would become `use Stuff\Mail as Mail1` and `use Tools\Mail as Mail2` in PHP. What's the difference?

The difference is that in PHP, the developers of "Stuff\Mail" and "Tools\Mail" would have to define "Stuff" and "Tools" as the namespace for their code.

In Python, they don't have to do anything. The project that uses the code decides.

Re: PHP – The Right Way

#70
post #33

Earlier quoted context omitted.

You hope there are no other libraries called mail in your import path. Let's take Python for example. With Python, I am in control of the import path. I can put those two mail modules in: stuff/mail tools/mail And then use them like this: from stuff import mail as mail1 from tools import mail as mail2 I don't have to hope for anything.

Isn’t this same thing? Your dir in python structure is dictating the namespace isn’t it?

The dir structure is defined by me.

Namespaces are defined by the 3rd party developer.

Post reply on HN