Wstęp
W listopadzie 2024 roku ma wyjść kolejna wersja popularnego języka programowania PHP. Niektórzy wręcz nie mogą się tego doczekać, a inni pomyślą „znowu będzie trzeba podnieść wersję”. Cóż.. Jak każda nowa wersja będzie dawać nowe możliwości, jak i będą co po nie co wymuszać nowe standardy kodowania.
W tym artykule będę posługiwać się anglojęzycznymi tytułami RFC bez ich tłumaczeń, aby później dało się łatwo na później wyszukać te zmiany. Przy okazji będziemy mogli też tak zweryfikować wraz z release ile faktycznie zmian zostało wprowadzonych albo co lepsze: jak zostały wprowadzone 😉
Wszystkie RFC jakie będę znalazłem na oficjalnej dokumentacji PHP: https://wiki.php.net/rfc#php_84
Deprecate implicitly nullable parameter types
Sprawa jest nieco niecodzienna. Kiedyś za czasów PHP 5.1 nie było możliwości deklaracji typu nullable (uni typów null|T) i problem rozwiązano tak, że kij z tym – wszystko może być null jako domyślna wartość parametru 😈… no słabo, ale część tego problemu rozwiązano w późniejszych wersjach, gdzie najpierw nullable robiono za pomocą znaku pytajnika przy typie np. ?T, a później przyszły unie typów null|T co de facto problem częściowo rozwiązało.
Dalej można jako typ parametru wpisać cokolwiek co nie jest nullable, a domyślną wartość ustawić na null. Powoduje to problemy i powiem, że nawet natknąłem się na to w swojej karierze. Stary kod po prostu tak musiał działać, ale nikt później go nie przepisał na nowsze standardy.
Proszę spojrzeć:
function foo(int $a = null): void {}Powyższa składnia nadal jest dopuszczalna, ale w nowej wersji taka składnia będzie uznawana za błędną i będzie zwracała wyjątek na poziomie Deprecated, a w wersji 9 PHP ma być już niedopuszczalna.
Natomiast bardzo łatwo idzie taki kod dostosować do nowej składni, bo wystarczy unia typów:
function foo(null|int $a = null): void {}i już. Bardzo łatwe.
Mając to na uwadze warto, aby już zająć się takim kodem, aby na później nie mieć tej roboty zwłaszcza że wiemy, że ta zmiana jest nieunikniona. Dobrą praktyką też jest po prostu używanie uni typów null|T czy ?T (to to samo) w nowym kodzie i mieć z głowy ten problem.
Grapheme cluster for str_split function: grapheme_str_split
O ile problem dobrze zrozumiałem to chodzi o obsługę grafemów. I tutaj proszę o komentarz o ile coś przekręcę: grafem to jest jakiś sposób napisania danej literki (polska wiki mówi o fonemie, ale już nie chciałem się za mocno zagłębiać). Aby to jakoś lepiej przedstawić poprosiłem ChatGPT o grafemy literki a:
Oczywiście, oto grafemy litery „a”:
ChatGPT
- „a” – to standardowy znak litery „a” w alfabecie łacińskim.
- „á” – znak litery „a” z akcentem acute, używany w niektórych językach, takich jak hiszpański czy węgierski, aby oznaczyć akcentowany dźwięk.
- „à” – litera „a” z akcentem grave, spotykana w języku francuskim i włoskim, gdzie ma różne znaczenia fonetyczne.
- „â” – litera „a” z daszkiem, używana w niektórych językach, na przykład w języku francuskim, aby oznaczyć zmianę wymowy.
- „ä” – litera „a” z umlautem, używana w języku niemieckim i innych językach, aby oznaczyć zmienioną wymowę.
- „ã” – litera „a” z tyldą, używana w języku portugalskim i niektórych innych językach, aby oznaczyć specyficzną wymowę.
- „ā” – litera „a” z kreską nad literą, używana w języku łotewskim i innych językach bałtyckich.
- „ą” – litera „a” z ogonkiem, używana w języku polskim i litewskim.
Nowa funkcja grapheme_str_split miałaby wspomóc z grafemami emotek. Np. emotka 🙇♂️ składa się tak na prawdę z dwóch znaków: 🙇 oraz ♂ co zwykły str_split pokaże, natomiast ten nowy miałby wykazać tylko i wyłącznie sam grafem.
Powiem, że problem dla mnie nie jest łatwy do zrozumienia, ale rozumiem, że jest potrzeba silnego rozróżniania grafemów.
Add http_(get|clear)_last_response_headers() function
Mają powstać dwie nowe funkcje http_get_last_response_header oraz http_clear_last_response_header, które mają zastąpić magicznie tworzoną zmienną lokalną $http_response_header, która powstaje w określonych warunkach.
Autor RFC zdaje się nie podał wszystkich przypadków kiedy $http_response_header jest tworzone, ale niewątpliwe jest to, że samo to, że magicznie nagle się pojawia przyprawia o dreszcze na plecach.
Za przykład można wziąć file_get_contents, który czasami jest wykorzystywany do pobierania danych za pomocą protokołu HTTP. Wtedy zrozumiałe jest to, że musi wyjść zapytanie (request) jak i w przypadku braku problemów odpowiedź (response). Zatem naturalne jest też to, że pojawią się nagłówki (headers), które może akurat będziemy chcieli sprawdzić.
Jak dla mnie wykorzystywanie file_get_contents do pobierania zasobów z sieci jest dziwne, bo sama nazwa funkcji tego nie sugeruje.
Mimo już tego, możemy się przynajmniej cieszyć tym, że będą metody do pobierania/czyszczenia headerów zamiast magicznie tworzonej zmiennej.
RFC1867 for non-POST HTTP verbs
Kolejna nietrywialna zmiana i pozwolę sobie opisać ją w skrócie.
Podczas przesyłania plików i używaniu przy tym metody HTTP POST przed uruchomieniem skryptu PHP dane były parsowane i pakowane do zmiennych superglobalnych $_POST oraz $_FILES (które swoją drogą są też tablicami). W raz rozwojem REST modne zaczęły być metody PUT i PATCH i chociaż nadal pozwalają na przysyłanie plików to już dla tych metod nie było automatycznego parsowania danych przy wysyłce plików, a programista musiał sobie jakoś z tym poradzić.
Głównie z tego powodu autor RFC zaproponował dodanie metody request_parse_body, która ma (jak to już jej sama nazwa mówi) sparsować dane i zwrócić je w dwuelementowej tablicy gdzie pierwszy jej element odpowiadałby zmiennej $_POST, a drugi $_FILES – też nie będzie potrzeby nadpisywania tych zmiennych, no ale autor RFC napisał, że to będzie możliwe.
Oprócz tego będzie dało się obsługiwać limity per endpoint, a nie jak wcześniej globalnie jak w pliku ini. Obsługiwane będą opcje takie jak:
- max_file_uploads
- max_input_vars
- max_multipart_body_parts
- post_max_size
- upload_max_filesize
Do wyjaśnienia posłużę się przykładem z RFC:
#[Route('/api/videos', methods: ['PUT'])]
public function index(): Response {
[$post, $files] = request_parse_body(options: [
'post_max_size' => '128M',
]);
// ...
}Taka nieco drobna zmiana, ale niewątpliwie może pozytywnie płynąć na rozwój popularnych frameworków jak np. Symfony czy Laravel. Oczywiście czy to wykorzystają to nie wiem, ale dam im szansę. W końcu byłaby to tylko zmiana na lepsze (takie dodawanie limitów per endpoint).
Change how JIT is disabled by default
W sumie taka drobna zmiana i myślę, że na tym mógłbym skończyć, bo tu na prawdę mało co można powiedzieć.
Obecnie, aby wyłączyć JIT trzeba ustawić opcache.jit_buffer_size na 0. Może to być trochę mylące, więc wymyślono że będzie wyłączany za pomocą opcji opcache.jit ustawionej na disable, a sam bufor będzie miał domyślną wartość.
Ta zmiana będzie kompatybilnie wsteczna, więc jeśli ktoś nadal będzie miał bufor ustawiony na 0 to będzie to znaczyło, że JIT jest wyłączony.
DOM HTML5 parsing and serialization
Obecne metody parsowania HTML w PHP nie zostały zaprojektowane z myślą o HTML5, który jak obecnie wiadomo stał się standardem współczesnego Internetu. PHP, aby nie zostać w tyle dostanie nowe klasy do parsowania HTML5.
Dlaczego nowe, a nie obsługiwać to starą klasą? Autor RFC chcę tak zapewnić pełną wsteczną kompatybilność na zasadzie: używasz stare? – spoko będzie działać! – a jeśli potrzebujesz nowe to tylko użyj nowe 😀
Sam problem przestawiłem powierzchownie, ale też opisanie RFC https://wiki.php.net/rfc/domdocument_html5_parser nadaje się na osobny artykuł.
Zakończenie
Tyle w części pierwszej, a co ciekawsze to nawet nie jest połowa, ale i tak dosyć sporo. Napiszcie co waszym zdaniem te zmiany w przyszłości przyniosą i czy przypadkiem coś z tego akurat wam się przyda 😀
Dziękuję, że jesteście ze mną i do następnego 😎
