PHP 4 je mrtvé – ať žije PHP 5

> Tato množina samozřejmě existovat bude - ale není to postavené na hlavu? Jak mohl vývojář píšící po uvedení PHP verze 4 bez křišťálové koule vědět, jak má psát, aby v budoucí (tehdy ještě neexistující pětkové verzi PHP) to bez problémů chodilo?

A jak mohl někdo kdo psal pro K&R C vědet, jak bude vypadat ANSI C? PHP je teprve v téhle fázi.

> Bez maker s proměnným počtem parametrů se obejdete. To není nic, než omezení syntaxe, ale nikoli možností jazyka.

Jak udělám funkci pro ladící výpis, která vypíše jméno funkce a pak formátovaný řetězec tak jako printf? S variadickými makry je to takhle:
#define DEBUG(fmt, ...) printf("%s: " fmt, __func__, ##__VA_ARGS__)

A mimochodem, kterým jazykem by jsi teda nahradil PHP? Ty snad píšeš stránky v ANSI C (něco takového jsem viděl, to co by bylo v PHP 5 řádek bylo asi 100 řádek v C, navíc s jednou bezpečnostní chybou)?

Java i .NET se vyvíjí podobně jako PHP, včetně změn co rozbijí staré programy, například přidávání klíčových slov (enum v Javě 1.5, group v .NET 3.0). Proti tomuhle je navíc PHP odolné, když proměnné začínají $ a můžeš mít klidně $class.

>A jak mohl někdo kdo psal pro K&R C vědet, jak bude vypadat ANSI C? PHP je teprve v téhle fázi.

Napište zdrojový kód v K&R C a přeložíte ho dnes také. Říká se tomu zpětná kompatibilita. Zdrojové kód v K&R C nemáte naprosto žádný problém přeložit dnešním C kompilátorem. Třeba takový vim se píše v K&R C dodnes a problémy nejsou.

Možná nejsem plně pochopen - Je možné napsat zdrojový kód v C tak, abyste MĚL ZÁRUKU, že ho kdykoli v budoucnu přeložíte beze změny jediného písmenka ve zdrojáku, pokud opravdu bude vyhovat nějakému standardu jazyka C.

V PHP máte velké kulové jako záruku, nemáte naprosto žádnou možnost, jak nějaké záruky na budoucí použitelnost zdrojového kódu získat. Nelze napsat žádným stylem v PHP zdrojový kód tak, abyste ho třeba za deset let zaručeně BEZE ZMĚNY zdrojového kódu použil. Nejde to, je to nemožné.

>Jak udělám funkci pro ladící výpis, která vypíše jméno funkce a pak formátovaný řetězec tak jako printf? S variadickými makry je to takhle:
#define DEBUG(fmt, ...) printf("%s: " fmt, __func__, ##__VA_ARGS__)

Já se zeptám jinak, jak v ANSI C vůbec zjistíte název funkce? Takové makro neexistuje a ani taková možnost v ANSI C není. Tudíž variadické makro Vám ani zde nepomůže, protože Vám chybí už tohle.

Ono je běžné, že že novější standardy dávají více možností, než předchozí standardy, a že C99 bude umět více, než ANSI C.

Pokud by možnost __func__ byla, a nebo byste se rozhodl sám takovou proměnnou definovat v každé funkci, pak to jde takto:

===========================================================

const char* __raw_return_fce(const char* fce_name)
{
return fce_name;
}

const char* __debug(const char* fce_name, const char* format, ...)
{
// zde pomocí va_list zavoláte vprintf a přidáte tam navíc jméno funkce
// jde to zcela bez maker a bez problémů v ANSI C
}

#define DEBUG __debug(__func__)__debug

===========================================================

Použití:

int main()
{
DEBUG("%d bleble %c\n", 12, 'a');
return 0;
}

> #define DEBUG __debug(__func__)__debug

Myslel jsi #define DEBUG __debug(__func__);__debug ?
Představ si co to udělá v kódu typu

if(i > 10)
DEBUG("i is %d, more than 10!", i);

Používají se triky jako
#define MACRO do { cmd; cmd; } while(0)
, ale to tím makrem co navrhuješ neuděláš.

Pardon, zhroutila se mi Mozilla Firefox, a odeslala rozepsaný kód, takže ho neberte vážně - kód odvolávám. Mozilla dokonce začla blbnout tak, že na klávesové zkratky dělala náhodné akce, tak jsem jí přeinstaloval. Takže to co tam bylo, bylo rozepsané a samozřejmě špatné. Já bych to nelámal přes koleno, ale udělal bych to jednoduše takto:

==================================================

int debug(const char* fce, const char* fmt, ...)
{
// tady uz je to jednoduche
}

int main()
{
static const char __fce__[] = "main";

debug(__fce__, "%s", "hello");
10 + 2 * 3;
debug(__fce__, "%d", 10*10);
return 0;
}

====================================================

Nicméně jak říkám, nedá se očekávat, že by novější verze neměla něco co nemůžete jako SYNTAKTICKÝ CUKR použít ve starší verzi. Jak vidíte tímto kódem udělám to samé, jen s menším komfortem.

Jasně, K&R prostě nebylo normováno, ale bylo prostě popsáno knihou. Nicméně se přiznám, že s uvedenými možnostmi jsem se nesetkal, takže díky za rozšíření obzorů. Jen mi proboha řekněte, k čemu je sčítání dvou pointerů? Z toho nemůžete dostat naprosto žádný použitelný výsledek a k ničemu to v praxi být nemůže. Proto bych ani neočekával použití v programech. Stejně tak co by vlastně měl dělat rozdíl pointerů dvou různých typů? Jakou operaci by měl provést, když výsledek je počet "prvků" mezi adresami pamětí? To co popisujete mi přijde jako nesmysl vůbec používat a já jsem se s programem toto používajícím opravdu nesetkal. V K&R jsem psal - protože kdysi ještě ANSI C nebylo, ale opravdu jsem toto ještě nikdy neviděl použít.

>A mimochodem, kterým jazykem by jsi teda nahradil PHP? Ty snad píšeš stránky v ANSI C (něco takového jsem viděl, to co by bylo v PHP 5 řádek bylo asi 100 řádek v C, navíc s jednou bezpečnostní chybou)?

Já nepíšu, že jsem nahradil PHP, jen že jsem se přesunul k jiných technologiím. Nicméně takový Python, nebo Java je daleko serióznější prostředek. Psát web stránky v C je sice možné, ale neefektivní (ono je vůbec neefektivní vůbec cokoli psát v C, když je tu C++, ale nechci vyvolávat flame).

Když to vezmete takto: PHP je v podstatě nejhůře vybavený skriptovací jazyk co existuje. Nemá zpětnou kompatibilitu, neustále se rozorává. Nemá binární tvar (respektive ve verzi 3 měl, ale dnes autoři se rozhodli ho dávat za peníze jako komerční produkt), nemá ve standardní instalaci debugger (což mají de facto všechny jiné skriptovací jazyky co mám), důvod stejný - autoři chtějí vydělávat na IDE a čím očesanější bude PHP, tím snadněji přesvědčí zákazníky. Kromě toho PHP dosud ani v nejnovější verzi nepodporuje práci s Unicode - pouze pár externích knihoven to zvládá. Neznám v podstatě žádnou rozsáhleji používanou serverovou webovou technologii s tolika nepříjemnostmi naráz.

Myslím si, že webovým jazykům by prospělo, kdyby slovo zpětná kompatibilita a norma jazyka začaly brát vážně. Nebylo by príma, kdyby autoři dali do oběhu dokument "norma jazyka PHP", kde by bylo jasně popsáno co bude navždy zaručeno do budoucna? Představte si, že by stejným přístupem jako je PHP trpěly i internetové standardy. Zrušili bychom bez náhrady současný HTTP protokol a vymysleli něco zcela jiného, naprosto a totálně nekompatibilního a nazvali to třeba NGP (New Generation Protocol). S tím, že bychom udělali akci GoNGP a vyzvali všechny, aby přestali používat HTTP a "prolomili ledy". Asi by to v praxi neprošlo, že?



>Java i .NET se vyvíjí podobně jako PHP, včetně změn co rozbijí staré programy, například přidávání klíčových slov (enum v Javě 1.5, group v .NET 3.0). Proti tomuhle je navíc PHP odolné, když proměnné začínají $ a můžeš mít klidně $class.

Vám trochu schází cit pro míru. Přidání jednoho klíčového slova je otázkou refactoringu programu, kde automaticky nahradíte jeden identifikátor jiným - dobré IDE to udělají v cukuletu za Vás a můžete mít 100% jistotu, že jste tam nezavlékl jedinou novou chybu. Navíc neznám kvalitního programátora, který by nazýval identifikátoru velmi kolizními jmény typu enum, class, apod.. a to v žádném jazyce.

Míry boření a destrukce zpětné kompatibility v tak obrovské míře jako PHP se hned tak něco nemůže rovnat. Problém je, že změny v PHP mohou zavést těžko hledatelné záludné skryté chyby, což těžko dokážete s kolizí klíčových slov - prostě kompilátor Vám ohlásí syntax error - a hned to vidíte.

Jinak Java i .NET je rozhodně bezpečnější jazyk ve smyslu, že tam daleko hůře zanesete takové chyby, jaké lze v PHP vyrobit běžně. A když jde o to, klidně si můžete v PHP pojmenovat proměnnou i jako mezeru, nebo konec řádku, akorát se s tím hůř pracuje.

> Já nepíšu, že jsem nahradil PHP, jen že jsem se přesunul k jiných technologiím. Nicméně takový Python, nebo Java je daleko serióznější prostředek.

Nová verze Pythonu nebude zpětně kompatibilní v ještě větší míře než PHP, skoro žádný skript prý nebude fungovat bez úprav. U Javy to je lepší, to uznávám. Nezmiňoval jsi Ruby, to je asi jediné kam bych možná přešel od PHP. Proti Javě je Ruby mnohem méně ukecané, viz třeba http://www.majda.cz/vyuka/2006-2007/swi113/slajdy.html#slide-29. Ale to je příliš mladý jazyk, takže jde těžko předvídat kam se vyvine a jak to bude s kompatibilitou.

> Zrušili bychom bez náhrady současný HTTP protokol a vymysleli něco zcela jiného, naprosto a totálně nekompatibilního a nazvali to třeba NGP (New Generation Protocol). S tím, že bychom udělali akci GoNGP a vyzvali všechny, aby přestali používat HTTP a "prolomili ledy". Asi by to v praxi neprošlo, že?

Ehm, slyšel jsi o IPv6? :o) V začátcích se dokonce jmenovalo IPng ("Next generation"). A v praxi to zatím bohužel moc neprochází, to je pravda.

>Nová verze Pythonu nebude zpětně kompatibilní v ještě větší míře než PHP, skoro žádný skript prý nebude fungovat bez úprav. U Javy to je lepší, to uznávám. Nezmiňoval jsi Ruby, to je asi jediné kam bych možná přešel od PHP. Proti Javě je Ruby mnohem méně ukecané, viz třeba http://www.majda.cz/vyuka/2006-2007/swi113/slajdy.html#slide-29. Ale to je příliš mladý jazyk, takže jde těžko předvídat kam se vyvine a jak to bude s kompatibilitou.

Nová verze Pythonu bohužel sice bude nekompatibilní (jedna nekompatibilní změna) - nicméně má dost velmi dobrých frameworků, umí bez problémů Unicode spolu s dalšími věcmi. Python je promyšlený jazyk.

Ruby jsem nezmiňoval, protože nejnovější verze Ruby je nekompatibilní už dnes - pod nejnovější verzí Ruby framework Ruby on Rails nechodí. Kromě toho Ruby neumí moc dobře Unicode - a pod řetězci v Ruby stále přemýšlím jako sekvenci bajtů, což mě přijde jako bych programoval v assembleru. Řetězec v Ruby pro mě prostě není řetězec, ale proud bajtů s nějakým kódováním nad kterými fungují některé knihovní funkce - tento přístup se mi hodně, ale opravdu hodně nelíbí.

Navíc mi řekněte, odečtěte Ruby on Rails - a co máte dál ve webu v Ruby na výběr?

Ukecanost jazyka není až tak silný argument - jde o udržovatelnost, podporu, serióznost, záruky, možnosti jazyka a další.

Ale nedejte se mnou zvyklat - pokud se Vám Ruby líbí, tak do něj. Ničeho se nebojte.

>Ehm, slyšel jsi o IPv6? :o) V začátcích se dokonce jmenovalo IPng ("Next generation"). A v praxi to zatím bohužel moc neprochází, to je pravda.

Tady máte zrovna krásný příklad jak moc těžké je prosadit zpětně nekompatibilní změnu - IPv6 se začalo tvořit před 16 lety - a stále ho skoro nevidět, ba dokonce není dodnes podporováno ani na většíně kořenových DNS serverů. A evidentně ještě mnoho let uplyne, než se v souvislosti s IPv6 o nějakém rozšíření bude dát vůbec mluvit.

Tady vidíte, že ani výhoda IPv6 (ona je v podstatě jen jedna - větší adresní prostor) nejsou dostatečné pro jeho rozšíření. Prostě ekonomické, technické, a jiné náklady a obrovské investice k tomu potřebné jsou brzdou.

A stejně tak proto si všimněte, že dlouhodobými stálicemi na poli programovacích jazyků jsou pouze Ty, které DÁVAJÍ ZÁRUKY ZPĚTNÉ KOMPATIBILITY. Jakékoli jiné jsou tu krátkodobě - i když to krátkodobě může znamenat cca max. 10-15 let. A také v těchto seriózních jazycích jsou dělány projekty, kde opravdu o něco jde. Můžeme to vzít začátku - COBOL, Fortran, Ada, C, ale také třeba unix shell (dokážete si představi jaké problémy by způsobilo znekompatibilnění sh?), a dále jazyky, které jsou tu krátce, ale touto seriózní kompatibilní a normovanou cestou tvrdě jdou: C++ například. Ve všech těchto jazycích jsou dělány obrovské a důležité projekty.

Klidně se ohledněte za 10 let po dnešku - a uvidíte sám, kde bude Python, kde Ruby, kde Perl, kde PHP - podle mě na ně budeme vzpomínat asi tak jako kdysi třeba na Basic, nebo na Pascal. Po každé změně syntaxe se prostě sníží procento vyznavačů a řada lidí odejde za něčím stabilnějším. Zatím jste mladý, jste nadšený a nevadí Vám investovat spoustu času a energie do přepisování a novém odladění chyb. Ale nebudete to tolerovat věčně.

Java je bohužel ukecaná víc, než je zdrávo, s tím zase musím souhlasit. Je až příliš osekaná, a dohání se to holt okecáváním.

Dneska už iterátory nejsou iterátory, ale v PHP5 exportují rozhraní (interface) třídy Iterator. Tak jsem si třeba já osobně do svých tříd v PHP dodělal možnost iterace přes cyklus foreach třeba. Stejné řešení používá například i Python, principem podobné (byť omezenější) řešení používá C++, které má v STL iterátory, atd..

Nezkoušel jsem to, jestli pole v PHP5 má iterátor jako proměnnou v poli, a nebo zda exportují interface Iterator, ale pokud to druhé, pak absolutně není problém iterovat stejné pole nezávisle ve svou funkcích aniž by se oovlivňovala. Ale test, zda implementace je a), nebo b) nechám na Váženém zájemci.

Miloslav Ponkrác

Myslím si naprosto totéž. Koneckonců každý programovací jazyk vzniklý, nebo inspirovaný Perlem skončí jako prasečina - můj osobní názor. Zatím jsem nenašel výjimku.

Mimochodem to makro DEBUG je špatně !!!

Co když to zavolám takto:

static const char format_pro_debug = "Index %d is out of range";

if (index > 10)
DEBUG(format_pro_debug, index);
if (index < 0)
DEBUG(format_pro_index, index);

Já osobně dávám přednost tomu, aby cokoli se tváří, že se volá jako funkce se také jako funkce volalo. A je dobrým stylem to takto dotáhnout. A v tomto případě vaše makro DEBUG selže, bude to syntax error při kompilaci.

Chybí mi tam závorky:

static const char format_pro_debug[] = "Index %d is out of range";

Pokud máš velký projekt, na kterém dělá několik lidí najednou, tak se ti stane, že si 2 lidé pojmenují stejně nějakou pomocnou datovou třídu (která není součástí domluveného rozhraní). A tomu jde právě předejít buď jmennými prostory, a nebo vnořenými třídami (protože ta datová třída obvykle patří k nějaké jiné třídě, která je součástí rozhraní).