Osobiście PHP 5.3 mam na swoim komputerze już od kilku miesięcy, na bieżąco testując to, co piszę, pod tą wersją. Właściwie jedyne kłopoty wynikały z kompilatora GCC, który w wersji 4.3 zawiera błędy uszkadzające implementację wyjątków, jak się okazało po konsultacjach na bugs.php.net :). Nowa funkcjonalność przede wszystkim przyda się programistom takim, jak ja, którzy zajmują się opracowywaniem bibliotek i frameworków. Głównie od pojawienia się narzędzi korzystających z przestrzeni nazw czy funkcji anonimowych uzależnione jest ich szersze wykorzystanie w komercyjnych przedsięwzięciach. Jednak tu napotykamy dwa problemy:
- PHP 5.3 upowszechni się na platformach hostingowych dopiero po jakimś czasie - wśród polskich hostingów wciąż można się natknąć jeszcze na PHP 5.1, a nawet PHP 4, co już jest moim zdaniem nieporozumieniem i oszustwem w stosunku do użytkowników. Bez dostępu do shella i udostępnienia odpowiednich możliwości, ew. posiadania serwera dedykowanego o samodzielnym skompilowaniu PHP 5.3 można jedynie pomarzyć.
- Przejście na przestrzenie nazw wiąże się z całkowitym zerwaniem wstecznej kompatybilności, co de facto oznacza konieczność rozpoczęcia zupełnie nowej gałęzi rozwoju, przy utrzymaniu wsparcia dla dotychczasowej.
Wygląda na to, że na dzień dzisiejszy jedynym bardziej znanym projektem, którzy przygotowuje już wersję wyłącznie dla PHP 5.3 jest Doctrine. O planach przebudowy Zend Frameworka nic nie wiadomo, natomiast Symfony pozostanie w wersji 2.0 przy dotychczasowym stylu nazewnictwa (aczkolwiek tu nie wiem, jak z wykorzystaniem innych elementów języka). Open Power Libs już od dłuższego czasu korzysta z możliwości PHP 5.3, ale tylko tych, które da się zaemulować na PHP 5.2. Innymi słowy, jeśli nie tworzymy oprogramowania całkowicie od zera, jeszcze dużo czasu upłynie, zanim będziemy mogli nacieszyć się nową funkcjonalnością, jednak aż tak bardzo bym się tym nie przejmował. Wiadomo, że aby coś było wykorzystywane, musi wpierw pojawić się w samym języku. Tak samo było z nowym modelem obiektowym, tak samo będzie i z tym.
PHAR
Istnieje jednak coś, co powinno zdobyć popularność dużo szybciej. Mowa o archiwach PHAR, wygodnym sposobie dystrybuowania bibliotek i całych aplikacji, który przy tym nie generuje dodatkowego narzutu wydajnościowego (o ile nie bawimy się w kompresję). PHAR-y działają także w PHP 5.2 po zainstalowaniu odpowiedniego modułu, bez utraty funkcjonalności.
Co mnie boli, to implementacje autoloaderów spotykane w bibliotekach, których twórcy idą po najmniejszej linii oporu i opierają wszystko na include_path, który może i jest dobry do uruchamiania programików narzędziowych w Linuksie, ale jego użycie do dynamicznych stron WWW, i to pracujących pod dużym obciążeniem, to spore nieporozumienie, co przyznają osoby tworzące PHP, które wypowiadają się na rozmaitych konferencjach nt wydajności. Przy takim modelu nie ma mowy, aby lokalizować właściwe archiwum PHAR na podstawie nazwy samej klasy, a tymczasem aż się o to prosi.
Z include_path zrezygnowali już twórcy Doctrine'a w wersji 2.0, dodając do autoloadera możliwość ręcznego ustawienia ścieżki. Również uniwersalny autoloader dla systemu nazewnictwa Pakiet_Element_Podelement z Open Power Libs wykorzystuje zupełnie nowe podejście ułatwiające korzystanie z wielu bibliotek spakowanych jako osobne archiwa.
Mała rzecz, a cieszy
Jak wiadomo, PHP zwalnia niepotrzebną pamięć obiektów automatycznie, jednak dotychczas oparty był wyłącznie o zliczanie referencji, które nie gwarantuje poprawnego odśmiecania. Jeśli uda nam się stworzyć cykl (A posiada referencję do B, B do C, C do A), taki obiekt będzie istnieć w pamięci aż do zakończenia wykonywania skryptu nawet, jeśli pozostała część skryptu nie ma już do niego żadnego dostępu. W PHP 5.3 możemy już jednak odpalić wyszukiwarkę cykli funkcjami gc_enable() i gc_disable(), tym samym zwalniając pamięć, gdy rzeczywiście jest to nam potrzebne. Osoby korzystające z frameworków raczej nie powinny się tym przejmować, ale twórcom bibliotek taka mała rzecz powinna się przydać.
Zakończenie
Zatem mamy już PHP 5.3. Przed nami najprawdopodobniej znaczące przyspieszenie prac nad wersją 6.0, w której dokonane zostaną bardziej drastyczne zmiany porządkowe, choć pewnie nie tak duże, jak wiele osób oczekuje... ja tymczasem wracam do składania środowiska webdeveloperskiego opartego o PHP dla Arch Linuksa.
Napisał Felix w wtorek, 30 czerwca 2009 o 17:55
A jak w tej wersji poradzić sobie z open_basedir na ALL w środowisku bez chroota? Czyli jak zabronić odczyt czegoś co nie jest użytkownika? Na razie nie mam pomysłu czytając dokumentację (może dlatego że nie ma jeszcze paczek dla OS i nie mam jak przetestować kilku pomysłów).