Nowości z php.internals – bazy danych

Część z Was pewnie wie o istnieniu listy dyskusyjnej php.internals. Jest to lista na której to core developerzy PHP rozmawiają o zmianach w języku. Jako, że praktycznie codziennie odwiedzam ową listę, postanowiłem co jakiś czas pisać post o aktualnych dyskusjach na niej oraz zapytać Was czyli społeczność o zdanie w poruszanych tam kwestiach.

Ostatnio najświeższym tematem na tapecie jest usunięcie z głównej dystrybucji PHP rozszerzenia SQLite w wersji 2 na rzecz wersji 3.

Proponenci argumentują konieczność usunięcia tego rozszerzenia tym, że biblioteka (i baza) SQLite w wersji 2 nie jest już rozwijana i trzymanie tego kodu w głównej dystrybucji jest bez sensu.

Przy okazji dyskusji kilka osób zaproponowało aby usunąć również nie rozwijane rozszerzenie mssql oraz rozszerzenie mysql oparte na natywnych bibliotekach dostarczanych przez producenta bazy, a zamiast niego silniej promować mysqli i pdo. Argumentacja była taka, że rozszerzenie mssql również nie jest rozwijane i są lepsze sposoby na komunikacje z tą bazą np. w windowsie oficjalny microsoftowy driver a na linkusie odbc.
Natomiast co do drivera mysql, że nie jest to natywny PHP-owy driver. Padł również argument, że powinno się ograniczać ilość dostępnych sposobów realizacji jednej rzeczy.

A Wy co sądzicie ?

Czy należy usunąć rozszerzenie SQLite2 z dystrybucji ?
Czy należy pozbyć się drivera MySQL dostarczanego przez producenta na rzecz mysqli i pdo, a może zostawić obie rzeczy by była lepsza kompatybilność wsteczna ?

  1. batman says:

    Moim zdaniem kompatybilność wstecz powinna być zachowana do jednej wersji w dół, przy czym korzystanie z funkcji, które mają być wywalone, powinno generować ostrzeżenie. Podejście takie pozwoli przechodzić na nowszą wersję języka w miarę bezproblemowo oraz umożliwić wprowadzanie nowych funkcji stosunkowo szybko.

    P.S.
    Fajnie, że będziesz śledził tą listę. Z chęcią poczytam analizy tego, co tam się dzieje.

  2. Wojciech Soczyński says:

    Pojawiła się tam propozycja, żeby np w funkcji sqlite_open generowało ostrzeżenie E_DEPRECATED. Co do jednej wersji w dół, pytanie czy mówimy o dużej wersji (3,4,5..) czy o małej (5.1, 5.2 … ) ?

  3. batman says:

    W przypadku PHP musiałoby to być kilka wersji mniejszych, np 5.0 -> 5.3 lub 4.0 -> 4.4
    Nowe wersje tego języka wychodzą w zbyt długich odstępach czasu, by bawić się takie coś.

  4. Ja dla odmiany śledzę nieco ‘inny’ fragment sieci, pod kątem planowanych (bądź nie) zmian w PHP. To co od pewnego czasu obserwuję jest strasznie niepokojące i sugeruję nam, że jeśli nie posiadamy softu, napisanego w PHP który w jakiś sposób odbija się szerszym echem w społeczności, to nie mamy co liczyć na uwzględnienie prywatnych opinii dotyczących zmian w języku – dla przykładu, propozycja planowanych adnotacji wyszła JEDYNIE ze względu na Doctrine. Sprawa ma się bardzo podobnie jeśli chodzi o ‘Deprecated stuff’. Developerzy ( Zeev, czy Pierre + kilku innych ) są bardzo mocno przywiązani do własnych obserwacji i ciężko jest ich przekonać do zmiany zdania – w przeciwieństwie do np. Rasmusa czy Rethansa. Wszyscy zapewniają, że jeśli czegoś chcesz, dasz patch to zostanie on uwzględniony – ale na internals i tak odpadnie :)

  5. piotrooo89 says:

    Fajnie, tylko co wtedy gdy będę chciał sobie upgradować PHP a tam nie będzie mojej biblioteki? Zdecydowanie powinna być kompatybilność wstecz. A to z generowaniem ostrzeżenia E_DEPRECATED IMHO bardzo dobry sposób i chyba mało inwazyjny.

  6. Wojciech Soczyński says:

    @krzysztof:
    no cóż nigdy nie dogodzisz każdemu, musi być ktoś, kto kontroluje to wszystko, tak jak już pisałem w którymś z poprzednich postów, trzeba mieć odpowiednią siłę przebicia żeby wprowadzić coś nowego, co jak co ale chcąc wprowadzić zmiany do języka którego używa taka ilość osób jak PHP trzeba mieć naprawdę dobre powody

    Z kompatybilnością wsteczną jest tak, że jedni chcą zawsze zrywania jej i rewolucyjnych zmian w języku (platońskie ideały piękna) a cała reszta się tylko będzie wkurzać, bo przedtem wszystko działało a teraz padło :>

  7. batman says:

    ~piotrooo89
    Kompatybilność wstecz powinna być zachowana jedynie w przypadku, gdy nie blokuje ona rozwoju danej technologii. Dosyć często się okazuje, że czegoś nie można wprowadzić, ponieważ gryzie się z jakimś starym kodem, który i tak nie jest wykorzystywany.
    Warto edukować użytkowników, że zrywanie z kompatybilnością wstecz tylko usprawni język i pozwoli go znacznie dynamiczniej rozwijać.

  8. Wojciech Soczyński says:

    @batman
    Pytanie tylko czy ta nowa technologia doda więcej niż odbierze usunięcie starej :>. Myślę, że najważniejsza jest edukacja i przedstawienie jakiś perspektywicznych roadmap oraz ścieżek migracji.

    Gdyby twórcy języka publikowali właśnie roadmapy co jakiś czas z podanymi terminami co kiedy dojdzie a co kiedy zostanie wywalone oraz świadomi użytkownicy edukowali tą rzeszę ludzi, których zupełnie nie interesuje co się dzieje i tylko sobie coś tam kodzą.To sądzę, że wtedy rozwój przebiegałby znacznie sprawniej.

    A co do wykorzystywania starego kodu, to chciano ostatnio wywalić możliwość tworzenia konstruktorów o nazwie tożsamej z nazwą klasy, ale okazało się, że bodajże w PEAR, połowa klas z nich korzysta i to tych pisanych pod PHP5.

  9. batman says:

    ~Wojciech Soczyński
    W idealnym świecie byłoby tak, że roadmap zaplanowany jest na najbliższy rok (może dwa) i jasno z niego wynika jaki będzie dalszy kierunek rozwoju.
    Nie żyjemy jednak w idealnym świecie i nie da się zaplanować więcej niż kilku najbliższych kroków.

    Twój przykład z PEAR pokazuje jak bardzo ważna jest edukacja oraz odpowiednie zgłaszanie ostrzeżeń. Może gdyby wpuścili świeżą krew do zespołu lub bardziej otworzyli się na społeczność, to PHP w końcu ruszyłby z kopyta.

  10. Wojciech Soczyński says:

    @batman: zgadzam się z tobą, szkoda też, że nie zrobią tego co developerzy Pythona – rozwijali branch 2.x a równolegle utworzyli branch 3.x w którym wywalili wszystkie zaszłości, potem portowali rzeczy z 3.x do 2.x te które się dało żeby ułatwić migrację…

  11. @piotrooo89
    Prawda wygląda tak: Nie upgrejdujesz po to, aby mieć to co już masz. Oraz nie upgrejdujesz produkcji z myślą, że zadziała wszystko od ręki (a jeśli to robisz, to głupie założenie). Właśnie dlatego oprogramowanie jest tworzone pod konkretne wersje środowiska – dobrym przykładem tutaj są np. wersje jądra linuksa. Developerzy oprogramowania/sterowników muszą się dostosować, ale oprogramowanie dla jądra 2.4 wcale nie musi działać z 2.6 bo nie dla niego było pisane pierwotnie. I tu pojawia się to o czym wspomniał batman i z czym zgadzam się w 100%. Roadmap jest po to, aby go realizować, PHP niestety takowego nie posiada i stąd wieczne problemy z dyskusjami na temat zachowania ów kompatybilności – popatrzcie jak daleko ‘oni’ starają się z nią sięgać. Maksymalnie dwie ‘małe’ wersje wstecz i DELETE – tak powinno być, samo core było by wolne od zaszłości historycznych jak i PHP od dziwnych powiązań ( jak EREG *DO TEJ PORY*, czy głupie aliasy dla funkcji – vide split/explode ).

  1. There are no trackbacks for this post yet.

Leave a Reply

Notify me of followup comments via e-mail. You can also subscribe without commenting.