PHP 8.0.0

Po pěti letech od vydání verze 7.0.0 byla vydána nová major verze 8.0.0 skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Nejnovější větev PHP přináší celou řadu nových novinek a vylepšení. Vydána byla také příručka pro přechod z předchozích verzí.

26.11.2020 17:33 | Ladislav Hagara | Nová verze

Komentáře

[zabijak]

Pouziva to nekdo v roce 2020? Neustale vyjasnovani rovnosti cisla a stringu je fakt vtipne

[Jendа]

Pouziva to nekdo v roce 2020?

Navrhni lepší alternativu. Cvičení: Python a třeba Flask → rezidentní aplikace trvale držená v paměti nebo příšerný overhead kompletní inicializace interpretru (nepoužitelné na multihostingu, kde je žilión takových věcí, na které skoro nikdo nechodí, na jednom stroji); v podstatě vynucený šablonovací systém místo napsání <?python kus_kódu(); ?> do existující stránky; z toho vyplývající „deploy“ a „reload“ a obecná nepřátelskost k lidem co se tomu nechtějí věnovat, ale chtějí rychle udělat jednu stránku se dvěma tabulkama.

[xkucf03]

chtějí rychle udělat jednu stránku se dvěma tabulkama.

+1

Přestože většinu softwaru píšu v Javě a mám ji rád, musím říct, že na takhle malé věci je PHP pořád asi nejlepší volba – a vlastně se mi v takových případech i líbí ten klasický přístup z dob, kdy PHP začínalo…

Ono sice pro většinu jazyků (včetně té Javy) existují líbivé tutoriály o tom, jak si uděláš webovou aplikaci napsáním pěti řádků kódu. Ale: jednak je to většinou větší prasárna než to PHP a skutečné aplikace se takhle nepíší a jednak to právě vyžaduje, aby na serveru běžel trvale nějaký proces a spotřebovával RAM. Přesně, jak píšeš:

rezidentní aplikace trvale držená v paměti nebo příšerný overhead kompletní inicializace interpretru (nepoužitelné na multihostingu, kde je žilión takových věcí, na které skoro nikdo nechodí, na jednom stroji)

[deda.jabko]

Navrhni lepší alternativu. ... obecná nepřátelskost k lidem co se tomu nechtějí věnovat, ale chtějí rychle udělat jednu stránku se dvěma tabulkama.

Je otazkou, pro co to ma byt alternativa.

Matne si pamatuju, ze nekdy v davnych casech, rikejme jim devadesata leta, slo udelat, ze server identifikoval element <script> a tak se daly delat server-side scripty v JavaScriptu nebo Visual Basicu. Ani jedno z toho neni zrovna lepsi alternativa, ale kdyby misto <?php ?> slo pouzit libovolny jazyk podle potreby, mohl by spouste lidi stacit i ten obycejny Python bez flasku, a byl by to krok vpred.

Pokud potrebujes rychle udělat jednu stránku se dvěma tabulkama je v zasade jedno, co pro to pouzijes, treba i bash.

Problem u PHP je, ze rada projektu preroste sve puvodni urceni nebo spis schopnosti svych autoru a stanou se z nich desiva monstra, ktera se objevuji ve statisicich ruznych instanci. Wordpress nebo phpBB jsou dokonale priklady toho, jak by se nemelo programovat a (to nejen v PHP), pouzivaji prasarny, o kterych se uz pred dvaceti lety vedelo, ze to jsou prasarny, ale presto to lidi pouzivaji se vsemi dusledky.

Je otazka, jestli u takto velkych veci uz by tou alternativou nebyl jiny civilizovany jazyk, treba ten Python nebo Java.

[xkucf03]

slo udelat, ze server identifikoval element <script> a tak se daly delat server-side scripty v JavaScriptu nebo Visual Basicu. Ani jedno z toho neni zrovna lepsi alternativa, ale kdyby misto <?php ?> slo pouzit libovolny jazyk podle potreby, mohl by spouste lidi stacit i ten obycejny Python bez flasku, a byl by to krok vpred.

Ono tím devadesátkovým stylem se dají psát i JSPčka – a taky se tak psala – prostě HTML stránka, do které sem tam vložím nějaký aktivní kód vykonávaný na serveru, sem tam třeba SQL dotaz atd. Víceméně se tak dá psát i dneska a je to hodně podobné tomu PHP.

Pak se na to <?php ?> taky můžeme dívat jako na instrukci zpracování XML (PI) a napsat si nějaký jednoduchý preprocesor, který rozparsuje XML, z těch ne-PI částí vyrobí něco jako echo "…" a ty PI části vloží doslova a výsledkem je skript v nějakém jazyce, který se akorát spustí a jeho STDIN (nebo výsledek volání nějakých metod/funkcí) se zase poskládá dohromady a pošle klientovi.

Takhle se dá snadno implementovat třeba <?bash ?>, <?perl ?>, <?python ?> nebo cokoli jiného. Není to těžké a dokonce jsem si říkal, že bych si to cvičně napsal. Ale úskalí tohoto přístupu je v tom, že se tu pracuje s textem, takže není zaručeno, že na výstupu bude validní XML/XHTML nebo že programátor nezapomene něco escapovat. Taky je to nešikovné pro plnění atributů. Dají se tím oIFovat třeba elementy nebo je namnožit v cyklu. Ale nepřijde mi to moc čisté. To už je lepší XSLT či XQuery. Pro jiné formáty než XML je taky potřeba, aby ten preprocesor rozuměl tomu vnějšímu formátu a věděl, co je instrukce zpracování a co tak pouze vypadá, ale ve skutečnosti je to třeba komentář nebo textový literál v tom daném formátu…

[deda.jabko]

Ono tím devadesátkovým stylem se dají psát i JSPčka

Tady nejde ani tak o styl, ten je dneska (dikybohu) vetsinou povazovany za prekonany. Ale slo mi o to, ze sel pouzit univerzalni element <script>, kde se v parametru nastavil jazyk a jestli se ma provest na klientu nebo serveru. Ale uz si nevzpomenu, kde a jak to fungovalo. V te dobe jsem byl rad, ze to nejak fungovalo a i tak jsem nakonec radeji mastil scriptu v Perlu. Matne si vybavuju, ze tam byly omezeni typu, ze tagy musi byt na zacatku radku, nesmi za nimi nic byt, apos.

Takhle se dá snadno implementovat třeba <?bash ?>, <?perl ?>, <?python ?> nebo cokoli jiného. Není to těžké a dokonce jsem si říkal, že bych si to cvičně napsal. Ale úskalí tohoto přístupu je v tom, že se tu pracuje s textem, takže není zaručeno, že na výstupu bude validní XML/XHTML nebo že programátor nezapomene něco escapovat.

Vystupem nemusi byt validni XML/XHTML. A muzes to udelat jednoduse, jak se prekladaji JSP.

Celou stranku prevedes na jednu velkou funkci/metodu/skript podle jazyka. Kde, co je textovy vstup (v tvem pripade XML) prevedes na nejako echo "<?xml..." nebo out.println("<?xml") a co je v processing instruction vlozis primo a pak to prozenes interpretem a co vypadne na STDOUT posles klientovi.

Pripadne pokud bys to chtel mit ala to moje reseni z davnych casu. Udelas si pruchod SAXem a narazis-li na element script vlozis kod a pokud nechces resit escapovani v kodu, vlozis to do CDATA.

To už je lepší XSLT či XQuery.

To me preslo nekdy kolem roku 2002.

[xkucf03]

Celou stranku prevedes na jednu velkou funkci/metodu/skript podle jazyka. Kde, co je textovy vstup (v tvem pripade XML) prevedes na nejako echo "<?xml..." nebo out.println("<?xml") a co je v processing instruction vlozis primo a pak to prozenes interpretem a co vypadne na STDOUT posles klientovi.

Ano, přesně to jsem se snažil říct, tím:

jednoduchý preprocesor, který rozparsuje XML, z těch ne-PI částí vyrobí něco jako echo "…" a ty PI části vloží doslova a výsledkem je skript v nějakém jazyce

Přemýšlím, jestli by to bylo užitečné… na jednu stranu je to takové trochu prasení a člověk se tam může snadno střelit do nohy, na druhou stranu je to implementačně jednoduché a zároveň hodně mocné. V některých případech by mohl být výstupem i zdroják, který se přeloží na nativní binárku, která se pak bude pouštět jako CGI nebo volat jako sdílená knihovna. V jiných případech by se to jen interpretovalo jako skript.

Ještě mne napadá k tomu:

Taky je to nešikovné pro plnění atributů.

ono by v těch atributech šlo rozpornávat {} nebo ${} (viz syntaxe JSP nebo XSLT) a akorát na tom místě přerušit uvozovky echo "…" / out.print("…") a vložit tam (escapovanou) proměnnou nebo vyhodnocený výraz z {}.

Vystupem nemusi byt validni XML/XHTML. A muzes to udelat jednoduse, jak se prekladaji JSP.

Šlo mi spíš o to, že když budeš chtít generovat třeba CSS nebo JavaScript, tak ten preprocesor musí rozumět těmto jazykům a vědět, že nemá interpretovat třeba /** <?bash … > */ protože to v daném jazyce je zakomentované, zatímco v XML by to byly dva textové uzly a mezi nimi PI. Ale pak by bylo potřeba mít způsob, jak v syntaxi toho jazyka najít jeho PI… Nebo to brát pouze jako text, tzn. ta šablona by byla XML, akorát by bylo nějak řečeno, že se její kořenový element nemá vkládat jako element, ale že se má vložit jen jeho textový obsah a interpretovat PI.

<text content-type="text/css" xmlns="…">
body {
    color: <?bash … ?>
}
</text>

Kde si ale veškeré escapování řešíš uvnitř těch skriptů, protože preprocesor té syntaxi kolem nerozumí a je to pro něj jen text.

[_]

A můžeš to nazvat třeba HSP - Hitler Server Pages. To by tak odpovívalo. Technologie na úrovni roku 1942.

[plostenka]

... napsání <?python kus_kódu(); ?> do existující stránky...

Sice existuje libapache2-mod-python, ale ten zda se tohle embedovani neumi. A pritom by to bylo velice prakticke na takove to domaci bastleni.

[Jendа]

A hlavně fuj blé Apache

[_]

OK, boomer.

[Luděk Postrašil (SEO UX Experts s.r.o.)]

Kdyby raději zapracovali na kompatibilitě s PHP 5.x. Ono je sice hezké si stavět vzdušné zámky a přidávat si nové funkce do osmičky, ale svět "tam venku" vypadá úplně jinak. Firmy mají spousty interních i webových aplikací napsaných nad PHP 5 (před lety je pracně a draze portovali z verzí 3 a 4 - a po téhle zkušenosti se jim už fakt nic přepisovat nechce).

Na druhou stranu si zase tak moc nestěžujeme - my totiž zákazníkům dodáváme balíčky s verzí 5 a podporu, sem tam nějaký ten backport nebo vývoj na míru a "vývar" je z toho docela slušný. Zákazníci o přepis / port na novou verzi moc nestojí, takže jim dáváme tu naší 5 nebo doporučujeme přechod na technologii CGI, což je nadčasová věc, která bude fungovat třeba i za dvacet let pořád stejně.

[O.V.]

porad stejne = single threadove a to o 20 let budes mit 256 jaderni procak i v hodinkach

[Jendа]

Wat, CGI přece spouští pro každý požadavek nový proces, takže naopak takto běží procesů libovolně mnoho současně. V čem je problém je ten overhead, zejména pokud je to napsané v něčem, co se dlouho inicializuje.

[xkucf03]

Problém CGI je v tom, že se pokaždé dělá fork(), takže při vyšší návštěvnosti je to neefektivní. Ale tenhle problém řeší FastGCI.

[Jendа]

Mně trvá fork (teda zkoušel jsem to ze shellu, možná to bude u webserveru horší, protože se kdovíjak duplikují věci -- ale na Linuxu je nějaký ne-tak-úplně-fork, který to řeší, ne?) zanedbatelně oproti následujícímu startu PHP nebo nedejbože Pythonu s několika importy.

[xkucf03]

Když to srovnáš třeba s tou Javou, tak tam už se pak volají jen metody. Procesy i vlákna jsou připravené předem a vše je načteno v paměti, takže je to hodně rychlé – ten fork() oproti tomu bude pomalý. Ale daň za to zase je to, že aplikaci musíš mít nastartovanou předem a žere ti RAM – což nechceš dělat pro ty spousty stránek, na které se jen občas přijde někdo podívat. Dá se to řešit různým uspáváním a případně i socket activation, kde pak uspaná aplikace nežere vůbec nic, protože běží jen super-server – rodičovský proces, který drží otevřený socket a v případě potřeby službu spustí. Ale k takovým optimalizacím většinou není potřeba přistupovat a obvykle stačí si vybrat jeden z těch základních přístupů (což někdy může být klidně PHP nebo CGI skript – a jindy zase klasický javovský aplikační server).

[Jendа]

A FastCGI musí mít podporu té aplikace/interpretru (třeba PHP to umí), ale když by to člověk měl dodělávat, tak bych radši vystavil lokální HTTP a z webserveru dělal proxy.

[_]

Dneska to uděláš jako mikroservisu pokud nechceš být sto let za opicema. Tzn. použiješ něco jako Helidon, Molecular, Quarcus nebo jiný framework. Ne, fakt to nebudeš šmudlat jako vlastní HTTP server spouštěný nějakým skriptem, to nejsou mikroservisy ale bastl.