Każdorazowo kolejne wydania języka PHP wprowadzają szereg większych i mniejszych zmian. zwykle nie są to rewolucje, bo PHP to ugruntowana i stabilna technologia. Zawsze jednak pojawia się nowość, która budzi dużo emocji i o której mówi się najwięcej. Taka flagowa funkcjonalność. W wersji PHP 8.4 to Property Hooks odegrają tę główną rolę.
Co do tej zmiany, ogólny wydźwięk na mieście jest pozytywny. Samo RFC przegłosowano aż 42 do 2. Przyznam, iż ja nie jestem aż tak wielkim entuzjastą tego pomysłu. W obliczu tych wszystkich pochwał i zachwytów znowu wyjdę na starego zgreda, który narzeka na każdą kolejną zmianę. No cóż, taka moja rola żeby dać sobie i Wam do myślenia. Takie krytyczne podejście pozwala używać technologii bardziej świadomie. A w tym wypadku, nie do końca widzę sens wprowadzenia tego mechanizmu. Być może się mylę – czas pokaże.
Świat bez property hooks
W PHP każde pole klasy, w zależności od zdefiniowanej widoczności, może być ustawione lub odczytane. Własności publiczne można zmieniać i odczytywać do woli. Własności prywatne są niedostępne z zewnątrz. Steruje się nimi dzięki metod. W takim najprostszym wydaniu, gdzie metody pozwalają na odczyt stanu i jego zmianę, są to najzwyklejsze gettery i settery.
Do nie dawna, z reguły, wyglądało to jak powyżej. Kolejne wersje języka pozwoliły na małe usprawnienia. Najpierw w wersji 8.0 pojawił się skrótowy zapis deklaracji pól klasy (constructor property promotion), który w przypadku tak prostych klas całkiem nieźle się wpasował.
Zauważcie, iż ten obiekt jest prostym opakowaniem na dane (DTO). Strukturą danych, która nie ma żadnych zachowań. Skoro tak, to dlaczego jego pola nie są publicznie dostępne? Na ten moment obiekt jest niemutowalny. Raz ustawione wartości nie powinny zostać zmodyfikowane. Z kolei ten problem został zaadresowany w wersji 8.1, od której pola mogą być oznaczone jako tylko do odczytu (readonly). W wersji 8.2 cała klasa może być zdefiniowana w ten sposób.
Czytelność kodu to kwestia mocno subiektywna, ale chyba zgodzicie się, iż powyższy kod jest przejrzysty. A co, gdyby imię i nazwisko miało być modyfikowalne? Przed wersją 8. wyglądało by to tak jak poniżej.
Za to wersja nowsza jest zdecdowanie krótsza i przyjemniejsza dla oka. Skupiam się tu głównie na aspekcie czytelnośći, bo w kwestii wytrwarzania systemu różnice są znikome. W samym IDE, bez większego zastanowienia, każdą z tych opcji generuje się w sekundę. Same pola readonly mają kilka niewielkich ograniczeń. Ciężko przypisać im domyślną wartość, a modyfikować można je tylko dzięki metod. Bezpośrednie przypisanie nie zadziała: $student->firstName = 'Krystian'.
Tak wyglądały proste DTO w PHP do tej pory. Tak naprawdę chodzi mi o wszystkie klasy będące tylko workiem na dane. W żaden sposób nie są one sterowane zachowaniami. Cała logika odpowiedzialna za wykonywanie programu jest gdzieś indziej, a powyższych obiektów używa się wyłącznie do przechowywania stanu. Jest to tak zwany model anemiczny. Celowo wziąłem na warsztat tego rodzaju reprezentację, bo jak zaraz zobaczycie, tytułowe Property Hooks będą właśnie celowały w tę kategorię. Przynajmniej ja nie wyobrażam sobie bogatego modelu domenowego reprezentowanego dzięki property hooks.
Czym są haki własności?
Haki własności (property hooks) pozwalają wprowadzać dodatkowe zachowania w sposób specyficzny dla pojedynczego pola, respektując jednocześnie wszystkie inne istniejące aspekty języka. Są alternatywą dla prostych metod typu gettery i settery lub rozszerzeniem dla bezpośredniego odwołania do pola publicznego. Umożliwiają krótszy zapis i redukcję ilości kodu. W świecie PHP są nowością, ale w podobnej formie istnieją w innych językach programowania. Przykład z wcześniej, zapisany dzięki nowej składni, wygląda jak poniżej.
Mam nadzieję, iż zauważyliście, iż powyższy kod działałby przecież dokładnie w taki sam sposób bez haków, bo własności są publiczne. Ale to punkt wyjściowy, bo do haków można dodać znacznie więcej, chociażby transformację danych czy walidację.
Dla jednolinijkowców, zarówno dla get jak i set dozwolona jest także skrótowa wersja strzałkowa. Analogicznie jak pokazuje to przykład poniżej. W przypadku set można też pominać typ i nazwę przekazywanej wartości. Wówczas typ jest tożsamy z definicją pola, a wartość przyjmuje domyślną nazwę $value. Tak samo dla pełnej i skrótowej wersji.
Ograniczenia property hooks w PHP
Pora na pierwsze ograniczenie. Property hooks działają mocno średnio z tablicami. Nie wchodząc w szczegóły techniczne, chyba lepiej od razu założyć dedykowane metody do modyfikacji tablic. Chociaż publiczna tablica w obiekcie zachowuje się w przewidywalny sposób, co prezentuje poniższy kawałek kodu, to własne haki już nie pozwolą na takie zachowanie. W sumie to słusznie, bo ta droga może prowadzić do nieoczekiwanych błędów. Z tablicami trzeba obchodzić się ostrożnie. Dwie sensowne drogi to: oznaczenie readonly dla publicznej tablicy jednorazowo ustawianej w całości lub prywatna tablica z dedykowanymi metodami.
Haki mogą być normalnie dziedziczone, nadpisywane w klasach potomnych, czy oznaczane jako finalne. Nie ma tu żadnego odstępstwa od reguły. Nie mogą być używane do pól statycznych, co jest logiczne. Ciekawsze wydają się interfejsy, które do tej pory nie pozwalały na definiowanie pól klasy. I słusznie, bo interfejsy mają definiować stabilną abstrakcję, a nie wchodzić w szczegóły implementacyjne. Trochę inaczej jest jednak w tym wypadku, gdzie z jednej strony narzuca się konkretne pole, ale z drugiej mowa w końcu o wymuszeniu metod get i set. Jest to dość dziwne, ale możliwe.
W pewnym sensie rozwiązuje to istniejący problem z polami tylko do odczytu, których w żaden sposób wymusić się nie dało. Trzeba było sięgać po stare dobre gettery choćby dla publicznych własności. W moim odczuciu to rzadka potrzeba, żeby tak proste obiekty opakowywać interfejsami, ale nie twierdzę, iż całkowicie zbędna. Przyznam, iż odkąd używam własności tylko do odczytu, kilka razy zdarzyło mi się zrobić getter dla takiego pola.
Naturalnie, jak to dla interfejsów – mowa tylko o publicznych własnościach, czy metodach. Nie ma szans na ustawienie innej widoczności. Podobnie zresztą mają się pola abstrakcyjne, choć te mogą być również chronione (protected). o ile chodzi o traity to wygląda to dokładnie tak samo jak przy bezpośredniej deklaracji w klasie.
Drugie ograniczenie dotyczy wspomnianych juz w tym wpisie pól readonly. Nie można łączyć tych dwóch mechanizmów. Pola tylko do odczytu nie mogą mieć zdefiniowanych hakow. Wykorzystanie haków nie pozwala więc stworzyć niemutowalnego obiektu, bo nie da się zablokować settera. Chociaż jak wspomniałem wcześniej, nowa funkcjonalność umożliwi wymuszenie interfejsem wymagalności pola tylko do odczytu przy jego domyślnym zachowaniu. Poniższy kod jest całkowicie poprawny.
Co z funkcjami do pobrania stanu
W PHP jest kilka opcji na odczytanie stanu obiektu. Co ciekawe, niektóre z nich zwrócą faktyczną wartość pola, a niektóre użyją haka. Poniżej kilka najbardziej używanych funkcji.
Opinia o wprowadzeniu property hooks
Można powiedzieć, iż property hooks to kolejny lukier składniowy. Tak naprawdę, sam PHP ma już coś podobnego, choć strasznie topornego. Dwie metody magiczne __get i __set, których chyba nigdy nie użyłem. Ale gdybym musiał to faktycznie haki przemawiają do mnie bardziej. Są znacznie czystszym i bezpieczniejszym konceptem.
Wprowadzenie tej funkcjonalności daje pewien komfort. Może zaistnieć potrzeba dekoracji zwykłego odwołonia do własności obiektu. Jako, iż wspomniane wyżej magiczne metody sprawdzają się tak sobie, z reguły jednak dodaje się dedykowaną metodę. Tyle tylko, iż to zmienia kontrakt. Trzeba znaleźć wszystkie wywołania w kodzie i je dostosować. Haki adresują dokładnie ten problem. Według mnie, ale też autorów RFC, haki nie powinny być domyślnym wyborem. Są raczej możliwością zrobienia tego w przyszłości, gdyby zaszła taka potrzeba.
Haki mają pewien niewdzięczny interfejs. Przy odwoływaniu się do konkretnego pola nie jestem w stanie ocenić, czy jest to zwykłe wywołanie, czy dzieje się coś więcej. Trudno powiedzieć, czy haki poprawiają czytelność. Według mnie, o ile te proste jednolinijkowce pewnie tak, o tyle przy dużej liczbie bardziej złożonych funkcji już niekoniecznie. Już od dawna, w PHP widoczny jest pewien trend redukcji linii kodu na rzecz skrótowych zapisów. Tylko w pewnym momencie dzieje się tak dużo magii pod spodem, iż ciężko się połapać.
Mniejsza ilość kodu nie jest gwarancją wzrostu czytelności.
Zauważcie, iż w tym artykule haki ustawiające spełniają rolę walidacyjną. To jeden z motywów wprowadzenia property hooks do języka PHP. Nie jestem przekonany, czy jest to odpowiednie miejsce na tego rodzaju logikę. Naturalnie, pamiętając o moim założeniu, iż haki będą wykorzystywane do prostych obiektów służących jako worki na dane. Chyba, iż ktoś chce wykorzystać je w swoim anemicznym modelu domenowym, gdzie taka bazowa logika walidacyjna może być w porządku. Mimo wszystko, ja widzę znacznie większe korzyści w modelu sterowanym zachowaniami z bardziej opisowymi metodami i pełną enkapsulacją. o ile model jest tylko naiwną reprezentacją tabeli w bazie danych to możliwe iż to dla prostych funkcjonalności będzie to wystarczające.
Ale czy haki byłyby w ogóle potrzebne, gdyby pozostać przy starych, dobrych własnościach prywantych z metodami typu getter i setter. Nie wydaję mi się. I to jest mój główny zarzut do tego rodzaju nowych mechanizmów języka. To nie jest tak, iż wszyscy muszą programować w jeden określony sposób. Tyle, iż pewna unifikacja powoduje, iż łatwiej jest się odnaleźć. Każdy z nas pisze kod, ale też czyta kod napisany przez innych. Mnogość rozwiązań daje pewną elastyczność, ale niestety podnosi próg wejścia. Ile mechanizmów trzeba rozumieć, żeby ogarnąć najbardziej prymitywny obiekt z kilkoma polami.
I jasne, nikt nie nakazuje mi używania haków własności. Jest choćby duża szansa, iż nie będę po nie sięgał. Problem jest taki, iż programiści rzucają się na każdą nowość, bo każdy z nas chce pisać nowoczesny kod. Tak jak nie byłem, i nie stałem się, fanem constructor property promotion to mimo wszystko używam ich na co dzień. Tworzę kod z innymi programistami, a takie pierdoły nie są czymś o co warto walczyć. Każdy ma swój styl, ale trzeba go trochę nagiąć do standardów w projekcie. Być może podobnie będzie z property hooks, choć publiczne pola tylko do odczytu wydają się być wystarczające dla niemutowalnych obiektów, a prywatne pola z metodami dla mutowalnych.
Wspomniałem już, iż ten mechanizm istnieje też w wielu innych językach. Skoro tak to podejrzewam, iż w PHP też znajdzie swoje miejsce i świat się nie skończy. Jednak obserwując pewien zachwyt tego rodzaju nowością w ekosystemie PHP musiałem podzielić się moim zgoła innym odczuciem. Zresztą ustawienie się w kontrze to moja naturalna pozycja. Niezależnie od tego, czy będziecie używać haków własności, myślę iż poza moimi opiniami, ten materiał przede wszystkim przybliżył Wam cały ten mechanizm.
Na koniec kombinacja wszystkich rzeczy opisanych w tym artykule. Mimo, iż kod w pełni działający to mam nadzieję iż się zgodzicie, iż jest to pewna patologia. Jak dużo czasu musicie poświęcić, żeby zrozumieć tak prosty z natury obiekt? Którym sposobem opisać nowododane pole? Czy naprawdę warto sięgać po tego rodzaju składnie tylko dlatego, iż jest czymś nowym?
Wpis Property hooks w PHP 8.4 – czy to naprawdę dobra zmiana? pojawił się pierwszy raz pod Koddlo.
