PHP 8

It worked surprisingly well, using similar multiprocessing techniques.

I wonder if that's somewhat on purpose. Part of the remaining stigma with PHP is that people cite bad PHP examples from WP.

This is an awkward side-effect of WordPress core team largely neglecting PHP code quality issues for the last decade or so. With good reason – improving such a large codebase is a massive, mostly-thankless task.

I mean seriously the first thing they list as a worry is that arithmetic operators will now throw an error when one (and only one) of their operand is an array or resource (eg array + array support remains, it's really int + array or string + file_descriptor, things like that). This is literally a case that makes no sense in the code ever, not one of the "php used to do something magical for us" but "php used to keep silent about this buffonery", so if your code does that you have bigger worries ...

Almost every single one of those things are easy to fix, in that it requires mostly time not much if any redesign, and almost every single one of those things are also deprecated or on their way out since at least a decade.

They are notably absent, and so people who write modern PHP - or wish PHP was a different language - are the ones influencing language development.

You get nice warnings for years about stuff to fix. If you ignore them because that is easier, there comes a point where it is so bad that you cannot recover.

I know the Wordpress codebase is nasty. But how and when are they going to fix these things? It is going to be so hard.

Report generation times:

PHP 7.4 = 67ms avg

PHP 8.0 = 66ms avg

This is getting the data from MySQL and massaging it for the templates. With Laravel's insane amount of indirection, of course.

That is shockingly poor practice and state of a code base for a product that powers so much of the web

https://www.mail-archive.com/internals@lists.php.net/msg4587...

Excerpt of the proposal:

So why am I saying all of this? Well, PHP up until 4 had a reputation for lots of bad coding style, spaghetti code, etc. With PHP 5 and better OOP, this reputation has lessened, especially with the great libraries out there (Zend Framework, Kohana, symfony, etc.) But there is still a problem. We (or at least I) would want PHP 6's reputation to be even better, and the reputation is largely based on how maintainable and cost-effective the code is, which is written by programmers actually using PHP. Blaming newbie programmers is one thing, and may even have some truth to it (PHP is simple - thus attracts newbies) but it's always good for a language to steer you in the right direction by default, and make it easier to write maintainable code.

PHP has a great opportunity to do this, by implementing a very simple change, turning all current PHP 5 code, and all code that will be written in the future, into maintainable code. Moreover, it won't break any existing code, like some other additions to PHP 6 might do. This one simple tweak will make PHP 6 code much more reusable and maintainable, just like namespace support will potentially make future PHP code more interoperable without having to write Artificial_Namespace_Class, like ZF and PEAR do.

  $name = 'foo';
  myFunction($name: 'bar');

  $name = 'foo';
  $array = [$name => 'bar'];
  myFunction(...$array);

  $name = 'foo';
  myFunction(...[$name => 'bar']);

Where this will bite people is when they do meta programming with functions that process functions and function signatures.

Maybe I'm missing something, but I find this to be another tragically missed opportunity. It's just unnecessary friction where there didn't need to be any, which makes me sad. At least they can add variable name support someday, because it's easier to allow something restricted than restrict something that used to work. Hopefully there is a "good reason" for this oversight.

Some frameworks like Symfony relied too much on shoving unstructured array options as arguments though, so if it helps making API strictier...

This particular post might want to get a reprieve – not because the discussion is interesting, but because the news itself – PHP 8.0.0 being released – is reasonably important.

Why not steal it?

Terrible, terrible, behaviour but there are lots of similar examples in PHP because it evolved over time rather than being designed as-is. Some of these things are being fixed over time, like this very example, others can't/won't be.

=== is strict.

What is "everywhere else"? You usually explicitly need to specify the type of comparison you want by writing either == or ===. "switch" is a case where the comparison operator is implicitly "==". "match" using "===" instead is one of the primary reasons for introducing it.

> In addition, the @ operator seems to have functionality changed, and there is plenty of other backwards incompatible changes to go along with it, and yet, one of the main reasons to not choice the @ symbol for annotation/attributes was because of backwards incompatibilities. Personally, I find the introduced syntax for attributes terrible, especially when @ is well recognised in the php community thanks to phpdoc annotations.

The only change to "@" is that it no longer suppresses fatal errors, which was generally not an intended or useful effect. The only thing this affects in practice are error handlers that don't check for error suppression being active correctly.

The "@" operator is still very much needed for certain use-cases (e.g. I/O functions may throw expected warnings) and removing it was not even a remote possibility for PHP 8, and as such also not a candidate for the attribute syntax.

It is worth noting that PHP uses the same attribute syntax as Rust does.

Likewise, the fact that ‘match’ is an expression rather than a statement encourages stricter semantics: although it’s technically unrelated to the type coercion issue, ‘match’ expressions should be easy to reason about locally, which isn’t the case for switch statements. This idea is encouraged by the fact that ‘match’ branches can’t continue across multiple lines: although technically ‘match’ could mutate some complicated global state, the intended use case is a constant or a simple function - easy to understand, and relatively gotcha-free. Gotchas should go in a ‘switch’ statement.

Seasoned PHP devs aren’t going to accidentally use the brand-new ‘match’ statement without careful study, and I don’t think the inconsistency is too big of a deal for newer devs: the overall principle is that ‘match’ is safer than ‘switch’ but less powerful.

Only downside is that there does seem to be quite a lot of (non-trivial) deprecations which is understandable but I wonder how long it'll take for 8 to percolate into production...

But I never found back to PHP after switching to JavaScript in 2011. If something new comes out it usually runs JS.

I started off with PHP3 and have a very great and hated time with it till v5. PHP for sure is difficult to maintain and very painful to debug, but it's not my reason leaving it. It's because JS began to pick up and started to do many tasks that requires no server rendering. The server sides started to become just API server, which no longer generate html on the fly. It's much scalable and easy to maintain.

Time flies, now I see the release of PHP 8 and I realise I have ditched it for a decade. Do I miss you? No.

That being said if you're not tied to PHP I'm not sure I'd necessarily recommend it. The obvious alternatives worth looking into are Ruby on Rails or Python with Flask or Django.

I think a better approach is to think of a (very basic) project you want to create, and then claw and bite your way through it, until you have something that works. Then think of a way to enhance it, and go though the process again. Slogging through a tutorial is boring, and you have nothing to show for it when you're done.

PS: Don't listen to sneaky JavaScript evangelists. Wicked! Tricksy! False!

https://phptherightway.com/

I can't personally comment on how well it works for websites but I have used PHP+SQLite for local ad-hoc GUI apps and it was a pretty nice experience.

https://getcomposer.org/

Almost all community code today is distributed with composer, anything from libraries to frameworks. Regardless if you write almost everything yourself or use a full featured framework, composer is always good to learn.

And even when you are a follower of KISS there always things that you don't care enough about to write yourself, boring things like logging frameworks (Monolog https://seldaek.github.io/monolog/) or testing frameworks (PHPUnit https://phpunit.de/). And composer can also help you set up class autoloading, a must for modern PHP.

Here you can find packages to download with composer https://packagist.org/

Next I would look into different frameworks, not necessary to use them but to learn about them and from them. The 2 biggest today is Symfony ( (https://symfony.com/) and Laravel (https://laravel.com/). But there are others like Slim (https://www.slimframework.com/), CakePHP (https://cakephp.org/), Zend (https://framework.zend.com/) and many more. Try a few and get the feeling how they do things and if you like them.

For view rendering you can do that with PHP out of the box (just remember to escape output!) or you can use a template engine like the more advanced Twig (https://twig.symfony.com/) or the simpler Mustache (https://github.com/bobthecow/mustache.php). Plates (http://platesphp.com/) uses native PHP templates but helps you create reusable layouts. Some frameworks include a template engine, e.g. Laravel uses Blade https://laravel.com/docs/8.x/blade.

For database queries I recommend reading this excellent article

https://phpdelusions.net/pdo

Many frameworks include their own query builders and sometimes a database layer (ORM).

Some semi famous people within the PHP community just released a PHP 8 book, I have not read it though.

https://front-line-php.com/

They also have free videos about PHP 8

https://spatie.be/videos/front-line-php

Ask for help https://www.reddit.com/r/PHPhelp/

Discussions about PHP https://www.reddit.com/r/PHP/

Online PHP shell https://3v4l.org/

Good luck!

there is learning PHP and its standard lib, learning how to avoid all the PHP pitfalls (because there are a lot of them when it comes to webdevelopment) then learning some mandatory framework because that's how you get an actual PHP job. These 3 things are separate tasks.

For the first frankly it's the documentation + stackoverflow, the second is https://phptherightway.com/ , the third is the documentation of whatever framework you are using. Final step is to learn how to use whatever server that will front your PHP app, Apache or Nginx.

Oh boy... I'm still not sure how you deploy a non-PHP webserver to be honest... every language seems to be doing something different, with php you just needed to drag & drop your files in the "public" folder.

but I disagree concerning register globals. I think it was the single thing that made php the most accessible language. we should bring them back but as a special variable with it's own prefix instead of $

IMHO that array/map data structure is one of PHP's biggest sin. So many bugs as the result of it and it makes a lot of codebases barely readable.

Is there such a function in php like "enumerate" in python, that yields a tuple of (counter, item) for each item in the first argument to enumerate? That is to say: is it possible to do what you're asking with composition rather than a language change?

    foreach ($iter = new IndexingIterator($array) as $k => $v) {
        echo $iter->index();
    }

foreach(myfunc($array) as list($key, $value, $loop)) {}

Maybe you can array destructuring at this place, i am not sure at the moment.

And your manual counting you do in myfunc() and just yield the values

However there is a difference: PHP has no deployment system included. But if you build that (not too hard) the difference isn't big ... (But with Lambda&others you outsource the management)

However, you have the multibyte string functions family that can operate in a wide range of encodings (including UTF-8 which is the default in any sane installation nowadays).

[1] https://www.php.net/manual/en/ref.mbstring.php

> The point is, if you look in the announcements and comments about what the JIT does you can pretty much guess why this is kind of the expected result. The JIT compiler improves performance for CPU-intensive work (for example calculating Mandelbrots) but not so much for the "default" kind of applications. We usually don't do all that many calculations.

Nowadays everyone uses PHP-FPM (again, written in C) which manages a pool of processes. Once a process is done serving a request, it is cleaned up and becomes available for serving another request. You can tweak the number of processes to control how much concurrency you want, or leave it to PHP-FPM to decide on its own. The process pool is much more efficient than the CGI method of setting up and tearing down a process every time, while preserving much of the conceptual simplicity.

PHP has had a built-in HTTP server since 5.4, but few people use it in production because PHP-FPM is so stable and performant.

ps: https://github.com/swoole/swoole-src/issues/1401 some performances benchmark (they compare it even with golang)

you mean crash your program? So your user finds a way to send you an int instead of a string, or vice versa, and now they can crash your webserver.

changes the shared nothing status of traditional php serving.

https://reactphp.org/

And that's for developing PHP itself. Documentation needs people too (there are many arguments for and against adding features without documentation) and the team would welcome new members.