PHP 5.6.0 z wieloma nowościami

PHP 5.6.0 z wieloma nowościami

    przez -
    23 687
    PHP
    Ogłoszono wydanie PHP 5.6.0. Wprowadzeno nowy operator ** (do potęgi). Uczyniono kodowanie UTF-8 domyślnym w ramach całego PHP (default_charset). Od teraz można wielokrotnie korzystać w ramach wywołania aplikacji z php://input, nie jest ono czyszczone po pierwszym użyciu. W GMP (GNU Multiple Precision) można użyć operatora +, który został przeciążony. Dodano funkcję hash_equals(), która ma za zadanie porównać 2 zakodowane hasła zawsze w tym samym, stałym czasie. Dodano również obsługę algorytmu hashującego gost-crypto.

    Udoskonalono obsługę SSL/TLS w PHP 5.6 (m.in. łagodzenie ataków renegocjacji TLS, obsługa certyfikatów fingerprint).

    • Roman

      PHP to dowód na to, że gorsze wypiera lepsze.

      • Tomek

        Hm… Ja tam tego wypierania nie widzę. Widzę za to rozwój oprogramowania z siły rozpędu. (Jest już dużo oprogramowania w PHP, więc kolejne oprogramowanie też piszemy w PHP; przy okazji wciąż ulepszamy PHP.) Czy to jest tańsze, niż przepisanie już działającego oprogramowania na inne języki? To pewnie zależy od konkretnego projektu.

      • PiotrM
      • TheBlackMan_dq

        Jak ja uwielbiam PHP-hejterów. Wy naprawdę nic nie kumacie.

        PHP to dowód, że bardziej kompatybilne i łatwiejsze w obsłudze wypiera mniej kompatybilne i trudniejsze w obsłudze.

        Porównując do pythona:
        – Python w wersji 3.0 zerwał z kompatybilnością wsteczną całkowicie. Ciekawe jaki to miało wpływ na jego adopcję.
        – Instalacja aplikacji w Pythonie wymaga często bibilotek instalowanych na prawach roota.
        – Apikację PHP napisaną 10 lat temu można rozpakować do katalogu i z niewielkimi zmianami uruchomić na LAMP z PHP 5.5 i BĘDZIE od razu DZIAŁAĆ. Bez roota, bez kombinowania. To jest właśnie potęga PHP. Spróbuj to samo zrobić z Pythonem.

        Sukces PHP = prostota + wydajność + kompatybilność wsteczna + ogromna ilość gotowych bibliotek na necie (nawet jeżeli wiele z nich jest niskiej jakości, to SĄ i DZIAŁAJĄ).

      • garrappachc

        1. Bo Python nie jest śmieciowym językiem, tylko czymś, co ma być przeznaczone dla programistów.
        2. O virtualenv Pan słyszał?
        3. Aplikację napisaną 10 lat temu i nie rozwijaną powinno się zaorać i zapomnieć o niej, a nie jeszcze uruchamiać.

        Sukces PHP = język tak prosty, że nawet pies potrafi w tym “programować”, co nie oznacza, że jest to język lepszy. Każdy szanujący się programista będzie stronił od tego wytworu.

      • TheBlackMan_dq

        “Każdy szanujący się programista będzie stronił od tego wytworu.”

        Jeżeli “szanujący się programista” będzie stronił od wytworu, który pozwoli mu napisać i *uruchomić* tą samą aplikację w 2 razy krótszym czasie używając 2 razy mniej zasobów, (przy czym aplikacja ta będzie tak samo wydajna i prosta w obsłudze jak w innym języku), to ten programista, z całym szacunkiem, jest idiotą.

        Przyznaję oczywiście, że w PHP jest spory bałagan wynikający z naleciałości starszych wersji, ale porządek trzeba sobie wytworzyć tam samemu, a nie oczekiwać aż język magicznie zrobi to za nas.

        W PHP *można* stworzyć bardzo ładnie/wydajnie działające biblioteki i frameworki – jeżeli kogoś to przerasta, to jest IMHO jego problem.

        Nóż, tak jak PHP, to tylko narzędzie. Najgorszy kucharz najwygodniejszym nożem wciąż zrobi śmierdzące gówno zamiast obiadu. Za to dobry kucharz nawet przeciętnym nożem zrobi wyśmienitą potrawę.

        Używanie języka programowania, który jest “modny”, “elegancki” lub “uporządkowany” nie zrobi z ciebie programisty. To są detale.

      • TheBlackMan_dq

        O, zapomniałem o czymś.
        [[[2. O virtualenv Pan słyszał?]]]

        Właśnie sprawdziłem na szybko co to. Odpowiedz mi zatem na pytanie.

        Czy za pomocą virtualenv mogę zrobić poniższe ?
        1. Zainstalować Pythona na serwerze
        2. Skonfigurować serwer WWW
        3. Rozpakować aplikację do folderu
        4. ???
        5. DZIAŁA !

        Jeżeli nie mogę tego zrobić, to Python wciąż jest 100 lat za murzynami.

        Wy ludzie naprawdę nic nie łapiecie. Ludzi (w tym mnie) nie obchodzi czy język jest superpiękny i uporządkowany. Obchodzą ich takie rzeczy jak:
        – Czy jest szybki
        – Czy jest skuteczny/efektywny
        – Czy jest wydajny

        PHP spełnia wszystkie te założenia, a po dodaniu dodatkowych zabezpieczeń (selinux/chroot etc) może być *NAWET* bezpieczny.

      • garrappachc

        Szybkość napisania czegokolwiek to nie jest jedyny wyznacznik dla programisty i nie powinien nim być. Jak masz gotową napisaną aplikację w Django i potrzebujesz cokolwiek zmienić czy dodać, to w zależności od konkretnego przypadku robisz to jedną lub kilkoma linijkami. Chodzi o utrzymanie coraz to większych projektów. Każda webaplikacja się rozrasta i kod trzeba jakoś utrzymywać. Drugą rzeczą jest to, że parser PHP jest uruchamiany za każdym wywołaniem strony. To naprawdę duzy narzut i serwery, które obsługują strony oparte o np. Zend Framework to nie jakieś-tam domowe serwerki. To są potężne maszyny. Następna rzecz – w PHP nie ma czegoś takiego jak konwencja programowania. Każda biblioteka, każdy dodatek ma prawo działać inaczej. Po chwili masz milion różnie działających modułów i tracisz czas na łączeniu wszystkiego w większą całość. W przypadku Django wszystkie dodatki są napisane w mniej-więcej tej samej konwencji, wiesz, czego się spodziewać. Wrzucasz katalog z pluginem, wstawiasz jedną linijkę w settings.py i to też PO PROSTU DZIAŁA. Virtualenv jest dla samego Django, pluginy możesz – jak już wspomniałem – po prostu wrzucić od katalogu z aplikacją. Doucz się najpierw, nie wypowiadaj się na tematy, o których nie masz pojęcia.

      • Michał

        To porównujesz django do php czy jak? Gdy w php uzywasz frameworka jak Zend czy Symphony to tez masz ścisłą konwencję narzuconą i modułu tylko wrzucasz do konkretnego folderu albo odpalasz tylko composera i też działa od razu, nic więcej nie musisz zrobić. poza tym dla całego języka stworzono standardy PSR-0 PSR-1 PSR-2 PSR-3 i PSR-4

      • anonim

        Jeśli ktoś ma coś działającego tylko pod Windows 98, a za sobą mamy już 8.1 – to mamy rozumieć, że to coś już nigdy nie uruchomimy? Myślący człowiek zrobi tak, że nie kupi Windowsa 8.1 (lub będzie miał obok) i problem się rozwiąże, skoro tak bardzo mu zależy, np.: na kosztach.

        Akurat kompatybilność wstecz nie zawsze sprawdza się. Wałkowanie złego może doprowadzić do stanu, że będzie jeszcze gorsze. Mało tego blokuje rozwój.

        Jak to się mówi, w życiu musi być męska dłoń i czasami decyzje typu: zerwaliśmy kompatybilność wstecz może wyjść tylko na lepsze, mimo tego, że jest to w pewnym rodzaju przeszkodą. Napisałem tylko w pewnym rodzaju, ponieważ jeśli komuś nie chce się przeprogramowywać softu, nikt mu nie zabroni używania starszej wersji biblioteki. Dlatego nawet pchanie w numerek wyżej powinno być mocno przeanalizowanie, a nie wytykać, że zabrakło kompatybilności wstecz.

      • Jakub Konieczny

        To że coś działa out-of-box postawione przez przedszkolaka nie znaczy że jest najlepszym rozwiązaniem. Sukcesem PHP jest raczej prostota hostowania wielu aplikacji na jednym serwerze, bo te „aplikacje” są zupełnie bezstanowe. To jest po prostu tanie, a amatorzy na to lecą – mogą szybko i tanio zabłysnąć w necie, sam z tego powodu zacząłem uczyć się PHP. Hostowanie Django wymaga już nieco więcej pracy, a sama aplikacja jest uruchomiona cały czas, nie tylko gdy ktoś żąda jakiegoś zasobu z niej.

        A gdy aplikacja się rozrasta, developerzy muszą sięgać po inne rozwiązania które łatają braki funkcjonalności niemożliwe do osiągnięcia w samym PHP (jak zachowanie stanu czegoś – trzeba zapisać na dysku/w bazie).

        Python zerwał kompatybilność, ale migracja wcale nie oznacza przepisywania od nowa, tyko co najwyżej poprawy kilku fragmentów (głównie printy, bo to one są powodem większości tych „niekompatybilności”). Zmiany są na + moim zdaniem.

        Instalacja niektórych bibliotek wymaga roota – niektórych, takich jak numpy i innych wymagających binariów, których instalacja na serwerze z PHP też wymaga roota, o ile ich użycie jest w ogóle możliwe i ma sens. Całą resztę można kopiego-pasta do katalogu z projektem wrzucić. Nie wspominam już o dobrodziejstwach virtualenv, które pozwala zrobić to samo bez roota.

        „nawet jeżeli wiele z nich jest niskiej jakości, to SĄ i DZIAŁAJĄ” – iście profesjonalne podejście. Osobiście wolałbym coś ręcznie napisać od zera niż użyć jakiegoś „pre-alpha testing but working”. Pewniejsze, a przy najmniej od razu wiem jak działa i wiem jak szybko poprawki zrobić w razie czego nie przedzierając się przez tysiące czyiś linii bez żadnej dokumentacji.

      • darekp

        > “Osobiście wolałbym coś ręcznie napisać od zera niż użyć jakiegoś „pre-alpha testing but working””

        Osobiście i ręcznie to można napisać kilkadziesiąt, góra kilkaset linijek kodu dziennie (w dużych projektach). A gdy trzeba napisać coś mającego 1-2 rzędy wielkości więcej (czasem co gorsza do nie daj Boże jednorazowego użycia), to już zaczynamy się rozglądać za jakimś gotowcem. I w przypadku PHP nie musi to być “pre-alpha testing but working”, tylko coś co jest “working” od paru lat. A PHP ma tych gotowców od groma, niestety (sam wolałbym, żeby proporcje uległy odwróceniu na korzyść Pythona ale nie jest).

      • Jakub Konieczny

        „Sam bym chciał ale tak nie jest więc dalej będę siedział w tym bagnie”.

        Problem jest taki, że często rozwiązania które gdzieś tam już są, są takie duże i skomplikowane bo są uniwersalne. W swoich projektach często nie trzeba nic uniwersalnego, tylko spełniającego odpowiednie wymagania i to robota czasami na góra kilka godzin.

      • darekp

        ” to robota czasami na góra kilka godzin”
        Wydaje mi się, że w takim myśleniu leży właśnie jest jedna z głównych przyczyn sukcesu PHP. Każdemu się wydaje, że sobie w nim poradzi. Bo “jest prosta stronka do zrobienia”, “dwie tabele na krzyż”, “w HTML-u mogę zrobić w dowolnym miejscu wstawki w PHP, więc sobie poradzę (i jeszcze zadziwię otoczenie swoimi genialnymi pomysłami)”…

      • Jakub Konieczny

        Ta, kod logiki wśród widoku/szablonu, świetny sposób żeby zawalić projekt.

      • asd

        To jest “niemodne” i “nieeleganckie” ale wbrew pozorom całkiem efektywne ;) mi w takiej konwencji łatwiej się odnaleźć niż np. programując w Javie i używając CDI+JPA+EJB :~(

      • darekp

        Zgadza się, nie można sprawy traktować dogmatycznie, że tylko MVC jest “jedynie słuszne” i wszystko inne jest be. Czasem taki “wymieszany” kod jest po prostu bardziej zwięzły i czytelny, niż te wszystkie “napuszone’ frameworki ;)

      • Damian

        Nic nie stoi na przeszkodzie aby w stylu Magento stworzyć szablon PHP do którego są przekazywane zmienne z kontrolera. Widok równie dobrze może być napisany w czystym PHP, byleby oddzielony od logiki aplikacji.

      • TheBlackMan_dq

        [[[To że coś działa out-of-box postawione przez przedszkolaka nie znaczy że
        jest najlepszym rozwiązaniem. Sukcesem PHP jest raczej prostota
        hostowania wielu aplikacji na jednym serwerze, bo te „aplikacje” są
        zupełnie bezstanowe.]]]
        1. No to może w takim razie aplkacje w Pythonie i Ruby tez powinny być bezstanowe, skoro ludziom to tak przypadło do gustu ?
        2. “Stanowość” ruby i pythona wcale mi się nie podoba. Bezstanowość PHP uważam za jedną z jego największych zalet. Nie – źle powiedziane – ja wprost UWIELBIAM bezstanowe aplikacje ! Znacząco ułatwia to debuggowanie oraz zmniejsza prawdopodobieństwo, że wyciek pamięci narobi nam bałaganu na serwerze, bo każdy nowy proces aplikacji trwa krótko, zamknięty w swoim mikro-kontenerku. Dodatkowo, aplikacja NIGDY nie jest w całości załadowana do pamięci ani uruchomiona, tylko za każdym razem inna jej część – dla mnie kolejna zaleta (jeszcze łatwiejszy debug).

        [[[To jest po prostu tanie, a amatorzy na to lecą –
        mogą szybko i tanio zabłysnąć w necie, sam z tego powodu zacząłem uczyć
        się PHP. ]]]
        A pomyślałeś, że potrzebny jest taki język, dzięki któremu można szybko i tanio zabłysnąć w necie ?
        Co Wy, “poważni programiści” sobie myślicie ? Że każdemu będzie się chciało grzebać na prawach roota i w bibliotekach systemowych, żeby uruchomić Wasze głupie aplikacje ?
        PHP – wystarczy rozpakować aplikację do katalogu i już działa. To jest zaleta, a nie wada.
        Tutaj Python czy Ruby są 100 lat za murzynami.

        [[[Hostowanie Django wymaga już nieco więcej pracy, a sama
        aplikacja jest uruchomiona cały czas, nie tylko gdy ktoś żąda jakiegoś
        zasobu z niej.]]]
        Jak już pisałem wyżej: wcale nie jest to dla mnie zaleta ! Wolę, gdy aplikacja NIE jest uruchomiona bez potrzeby.

        W PHP też można napisać aplikację – daemona (jedna instancja uruchomiona cały czas i odpowiadająca na żądania), jeżeli jest taka potrzeba. Tylko, że w >95% (z własnego doświadczenia) przypadków nie ma takiej potrzeby !

        I to jest właśnie piękne w PHP.

      • Jakub Konieczny

        Aplikacja nad którą w tej chwili pracuję komunikuje się non stop z innym silnikiem pracującym na innym serwerze po to żeby wyświetlać stronkę. Mielenie bazy danych byłoby głupie (danych jest tak dużo i są tak często aktualizowane, że nawet nie ma sensu tego przechowywać), podobnie jak wysyłanie non stop zapytań do silnika. Backend strony po prostu cache’uje dane potrzebne do wyświetlenia i uaktualnia je gdy przychodzą nowe z silnika, podobnie jak parę przerobionych danych, których przerabianie właśnie „trochę” trwa. Czy to przeszkadza w debugowaniu? Jeśli się te stany przechowuje rozsądnie to nie, jakoś PHPowe frameworki protezują taką możliwość.

        Oczywiście, zapotrzebowanie na PHP jest, dla stron firm, blogów i innych niewymagających. Ale napisać jakąś aplikację na szybko nie stawiając sobie żadnych technologicznych ograniczeń?

      • PiotrM

        Daemonizowanie aplikacji PHP jest w >95% zbędne, bo serwer webowy jest daemonem/serwisem. To kolejny plus tym razem stosu serwerowego “LAMP” (każdy element tego stosu można wymienić) nad zintegrowanymi rozwiązaniami.

    • Pingback: Fedora 21 z eksperymentalną obsługą Waylanda - Linux mint, centos, ubuntu - OSWorld.pl - mały świat wielkich systemów!()