PHP 8 3 Released

preview_player
Показать описание
Recorded live on twitch, GET IN

MY MAIN YT CHANNEL: Has well edited engineering videos

Discord

Hey I am sponsored by Turso, an edge database. I think they are pretty neet. Give them a try for free and if you want you can get a decent amount off (the free tier is the best (better than planetscale or any other))
Рекомендации по теме
Комментарии
Автор

Php is actually fine now. it's not the most flashy or modern experience but it's good enough. Pair it with laravel and it does a lot of things right.

steveaguay
Автор

PHP has been good for years.

At the same time, old, unsupported, terminally insecure PHP versions have become the IE6 of backend development.

If you learn PHP and want to use that skill for money you have to be super duper extra careful not to end up working on one of these legacy backends, and they are LEGION.

There are tens of thousands of company/corporate sites running PHP versions that haven't seen a security update in over a decade. 😨

Taverius
Автор

The clone stuff is actually brilliant. It's for immutability.

Suppose you have a readonly class. You can have its properties be public and readonly - so no getters. But before PHP 8.3, you could not derive new copies of instances of readonly classes, unless you go through the constructor.

So now we can have a class with immutable methods that can efficiently generate cloned derivations.

Ex: $user->withName("New name");

Internally, `withName()` would clone $this and update the name property on the cloned instance.

fus-ro-dah
Автор

PHP still has the most potential in its Foreign Function Interface, as the language was designed with that in mind in the first place. It’s a shame they do not focus more on making that part of the language more user friendly.

roelhemerik
Автор

I really do wonder whether Prime would like Laravel or not. IMO Laravel is an antithesis to anyone who likes Go. Go is all about simplicity while Laravel is all magic and abstractions upon abstractions. I would say Laravel is more akin to React or Next.js specifically in that in React/Next.js you are not writing just plain JS, but the React way of writing JS. Similarly, Laravel is not really PHP at this point, but almost like its own language built on top of PHP. Also, just as there are many people who learn React before they learn vanilla JS, there are also many people who jump straight into Laravel without bothering to master PHP and I don't think that is a good thing in either case

justjess
Автор

Random note, a theory on why the PHP namespace delimiter is `\` is because the foreard slash `/` was already the division operator so it was easier at the time to drop the backslash into the parser.

Similar reason as to why it didn't use the `::` operator C++ uses, since it was already in use for static calls.

mme
Автор

I can feel how Prime wants to do a serious project on Laravel.

fcolecumberri
Автор

Sounds like the deep clone is for updating immutability. So you can change, dump the old object, and move forward with the new.

j.p.
Автор

I became a dev in 2019 and in 2020 we had to use PHP for the first time. Even "back then" we still were corrected that PHP is not that slow thing it gets the rep for. Just like Java and C# there were plenty of perf optimizations over the years. Now I personally cannot prove it but I trust the people who told me. Also the project we did ran pretty flawless under PHP. Tho I never really got involved with PHP again :D

Kiyuja
Автор

If javascript can be used for writing backends, its time that php gets used for making frontends

echoptic
Автор

Really love your content. Although I have to play it at half speed at times, to understand what you are saying (or play it more than once :) ). Keep up the great work!

robmies
Автор

The deep clone of read only seems like a way to ensure that your clone does not reference a read only property. It makes a whole new one, and since it's wholly new you can alter the field before it's actually instantiated with read only.

If you deep cloned an object with 12 properties, 3 of them are nested read only objects, and one of those read only objects has a value that needs to change—that's where the new feature helps. Since you're only altering one of the nested objects, it can reference the ones that aren't changed and make a new object for the ones that do change.

I imagine having a user update their information, but wanting to ensure that it doesn't accidentally get updated elsewhere, is a use case. But I'm a noob and have no idea.

connorskudlarek
Автор

PHP is really great for small to medium projects...even big projects if you configure it well...Also Laravel + InertiaJS is a gamechanger...And for those who say PHP is slow, how many users do you have?

Dantee
Автор

One reason I can think of for doing this is cloning ORM models and you want to clone the table row but change the ID on the model internally. This way you don't have to move data between the database and the API server.

zebraforceone
Автор

7:19 the had a better namespace separator when they first introduced the concept, but then they changed it to a / at the last. I think the separator was ::, which is used to access static members.

brnto
Автор

For the cloning of readonly one, deep cloning could not be done before. For those that don't understand this concept, because PHP passes all objects (i.e., class instances) around by reference, if when cloning, you don't also clone the underlying object and re-assign on the newly formed object, then it will still be pointing to the old one, which means if that is then mutable and mutated, it will essentially mutate it in all clones. In the example provided, the PHP class is mutable, so if you didn't reassign the internal ->php on clone, but then cloned the Foo object and then modified the php version, like in the 8.3 version, then the original Foo object you cloned from has the same value. Now, with the 8.3 example, modifying the $clonesd->php->version does not modify it for $instance->php->version. In 8.2 this wasn't possible.

I hope that's clear?

MarisaClardy
Автор

The short-term mutability of a deep-cloned, readonly object seems really nice. In JS you'd have to do something like
> const x = { ...data, nested: { ...data.nested, foo: 123 } };
whereas Elixir would have something like
> x = put_in(data, [:nested, :foo], 123)
So this seems pretty similar to the latter. Looks neat.

j-wenning
Автор

5:51 - That exists since if you have a read-only property on a class (like “Foo” in this case) that you want to clone, you can’t do a _deep clone_ because that property cannot be updated to be cloned as well (hence the “deep” clone of the lower down references). This update fixes that I guess.

patricknelson
Автор

5:47 as someone who has written PHP near daily since the ye ol' PHP3 days.. I don't get the deep cloning situation. I can't even think of a scenario where I'd find myself in where that'd be a useful or even desirable thing to do

KyleHarrisonRedacted
Автор

how could you overlook the new mb_str_pad()

MattDog_