Wpis z mikrobloga

Jak mnie wnerwia ten brak kompatybilności wstecznej w PHP. Właśnie piszę nową stronę www opartą na Koseven, najnowsza wersja z github, przystosowanym przez programistów już do PHP 8 i lokalnie mam tą wersję PHP i wszystko gra. Tymczasem wcześniejsze projekty na starszych wersjach Koseven przystosowane do PHP7 już na PHP 8 nie działają. Wrzucając nowy projekt na Koseven pod PHP 8 na testowy serwer ze starszą wersją PHP musiałem wrzucić pliki z system i modules ze starszej wersji frameworka bo oczywiście nie działało. Zabawy z podmianą systemowych plików i modułów frameworka jak auth czy orm żeby działało na konkretnej wersji PHP. Dobrze że znam ten FW na wylot bo inaczej byłoby ciężko.

Z Bootstrap 5 też podobna sprawa. Pozmieniane nazwy klas CSS, kiedyś webowe projekty robiłem w Bootstrap 3. Fajnie że z jQuery i Knockout.js przynajmniej nie ma tych problemów. Generalnie jednak z Bootstrap 5 nie widzę problemów, fajnie się na nim pisze frontend ale ten PHP mnie denerwuje niesamowicie.

Pytanie jest takie. Na podstawie jakich to przesłanek i kto podejmuje decyzje o zmianach w PHP i dlaczego są one niekompatybilne? Zamiast jakiegoś komitetu standaryzacyjnego i standardów w stylu ISO przez jakieś fanaberie programistów jest wiele problemów. Czemu Koseven, jQuery i Knockout.js? Bo tylko w tych technologiach jak dotąd jestem mocny a że robię na zlecenie jako freelancer, nie mam odwagi podjąć się projektów np. na Laravel czy Symfony i React, VUE albo angular.

#programista15k #programowanie #php #javascript #css
  • 27
@Malkof: w C++ masz zamrożone ABI, zmiany w języku zazwyczaj polegają na tym, że coś się nie kompiluje co jest super proste do naprawy. Dużo większym problemem nie jest sam język co same framworki/liby, które mogą korzystać z niewspieranych ficzerów.

Taka np. Java: na papierze idealny język do upgradowania: prosty kompilator i bajtkod, mało zmian w kolejnych wersjach, runtime wspiera stare jak i nowe wersje w taki sam sposób, jednym słowem:
@Saly: Nie wiedzieć czemu w PHP w pewnych funkcjach pewne rzeczy są deprecated i już framework nie działa. Zamiast dodać nowe funkcje i nowe operatory tak żeby zachować kompatybilność to nie, bo lepiej niech niektóre funkcje już nie przyjmują np. NULL albo count($zmienna) bo musi być array. Kompletnie nie rozumiem takich zmian. Niby na lepsze bo się profesjonalizuje ale właśnie z frameworkami są problemy.
@daro1: Kod używający ficzerów z nowej wersji nigdy nie będzie działał na starej i nie ma to nic wspólnego z kompatybilnością wsteczną (BC dotyczy języka, którego nowa wersja obsługuje stary kod). Poza tym BC w php łamane jest tam gdzie ma to sens, a i tak robią to za wolno moim zdaniem.

Na przykład niedawno ktoś od Symfony się zesrał, że jakaś funkcja (unserialize chyba) mogłaby konsekwentnie rzucać wyjątkami, a oni
lokalnie mam tą wersję PHP i wszystko gra. Tymczasem wcześniejsze projekty na starszych wersjach Koseven przystosowane do PHP7 już na PHP 8 nie działają.


@daro1: Pierwsza sprawa, to wydaje się, że źle podchodzisz do problemu. To nie do lokalnej wersji PHP należy dostosowywać projekty (chyba, że celem jest refaktoryzacja) , tylko odwrotnie - lokalne środowisko do projektów.

Od wielu lat jednoczesne korzystanie z kilku wersji PHP, apache, ngnix, mysql i wielu
@Serghio: Problem polega na tym że ja nie mam wpływu na to jaka wersja PHP jest na serwerze na który wrzucę projekt a jest opłacony i wybrany przez zleceniodawcę. A lokalnie mam XAMPP z PHP 8. Dobrze że znam na wylot framework i ewentualna podmiana może dotyczyć tylko system i modules a nie plików aplikacji, bo tam wszystko piszę tak żeby było uniwersalne. Jakby tego było mało raz nawet na serwerze
@Sunekkk: Od razu właśnie robię pod PHP 8. I Bootstrap 5. Tylko że nie mam wpływu na to co jest na serwerze produkcyjnym. Zleceniodawca ma opłacony serwer a i on sam nawet nie wie jaka jest wersja PHP bo się nie zna i nie musi.
Czemu Koseven, jQuery i Knockout.js? Bo tylko w tych technologiach jak dotąd jestem mocny a że robię na zlecenie jako freelancer, nie mam odwagi podjąć się projektów np. na Laravel czy Symfony i React, VUE albo angular.


@daro1: jak przejdziesz na jakieś laravel + vue to sobie podziękujesz, a jednocześnie będziesz sobie pluł w brodę, że nie zrobiłeś tego wcześniej. to nie jest jakieś trudne
@seanconnery: No to jest jasna sprawa tylko że opanowanie tego do poziomu pozwalającego na realizację zleceń na małe portale www to jakieś min rok czasu. Dobrym przykładem na poziom skomplikowania jest kod 4programmers na githubie. Ale faktycznie do freelancingu Laravel może się lepiej nadawać niż Symfony.
@Szubrawski: No to są inne funkcje np. hash albo count gdzie już pewne rzeczy są deprecated. No niestety frameworki to trzeba znać na wylot i ja bym tu nie liczył że programiści szybko coś zaktualizują.
@daro1: ale co tu wymyslac skoro jest statyczna analiza, zarowno w FW (jesli jest dokumentowany np w doc block) jak i samym jezyku, wykrywa i informuje o uzyciu funkcji deprecated, wiec o czym ty mowisz?! niby co w count i hash jest deprecated?
@Szubrawski: W count teraz przyjmuje array a nie jak dotychczas zmienną nie będącą array np $a=1 i count($a) było 1. W hash deprecated jest null i tego nie przyjmuje. I tak to nie tylko FW ale niektóre biblioteki w starszych wersjach nie działają, np. musiałem zaktualizować HTML Purifier bo coś tam z __autoload było deprecated.
@daro1: chyba nie za bardzo rozumiesz czym jest deprecated, dodali jedynie warning o tym ze wrzucasz bledny typ do count, z hash podobna sprawa, problem jest po stronie twojej lub FW, wrzucasz mixy bez sprawdzenia czym sa i jeszcze masz pretensje ze sie sypie a dwa warning nie jest fatalem...

@Szubrawski: Ale to nie we frameworku jest problem tylko w tym że jak wrzucam projekt na serwer produkcyjny to nie mam wpływu na to jaka jest wersja PHP. No chyba że można wybierać. Obecny projekt piszę w najnowszej wersji Koseven przystosowanej już do PHP 8. I co? A no to że wrzucając projekt z tą najnowszą wersją na serwer produkcyjny ze starszą wersją PHP musiałem wrzucić systemowe pliki frameworka ze starszych