Vlákno názorů k článku PHP konečně s podporou unicode od johny - a o rok bude "php konecne s podporou...

a o rok bude "php konecne s podporou nasobenia desatinnych cisel" :D

To se mi moc nezda, kdyz jsem to naposledy zkousel, tak treba regexpy fungovaly po bytech a ne po znacich, coz mi prijde jako nesmyslne chovani, kdyz je to nastroj pro praci s textem a ne s byty.

Byl bych vdecny kdyby nekdo tady specifikoval co se presne mysli tou podporou unicode, ktera "konecne" ma prijit, a ktera ted neni v php.

Ne, současné PHP Unicode nepodporuje, měla by ho podporovat až verze 6. Všechny řetězce jsou akorát posloupnosti bajtů, bez znalosti toho v jakém jsou kódování ani nespočítáte délku řetězce. Třeba strlen("čau") vám klidně vrátí 4, pokud je skript uložen v UTF-8. Jde to sice obejít pomocí knihoven jako je mbstring, ale to nejde nazývat podporou Unicode.

PHP == pekne hnusne programovani.

1. Kolik hostingu uziva nejnovejsi verzi?
2. Dle materialu, ktere jsem procetl az 80% scriptu zkoumanych bezpecnostnimi odborniky obsahuje zavazne chyby.
3. Dle coding standardu je jednoznacne urcena syntaxe a presto ji samotni vyvojari jazyka nedodrzuji, spravny zapis funkce je: function some_bloody_function()..., jenze funkce v PHP, ktere byly naprogramovany v perlu se zapisuji jako function somebloodyfunction a nakonec tu mame jeste C-ckare, kteri si oblibili function someBloodyFunction + samozrejme nekde byl pouzit i spravny zapis some_bloody_function.

A tak pokud dela na jednom projektu vice lidi, syntaxe je ruznoroda, od chybneho odmezerovani az po chybne urcene nazvy funkci, konstant ci promennych. Je opravdu slozite zvyknout si na takovy chaos a zapamatovat si napriklad htmlspecialchars() oproti takovemu array_diff_uassoc() a k tomu vedet, zda pouzit php_info(); ci phpinfo(). Clovek se musi doslova biflovat kde jsou podtrzitka a kde nejsou. No alespon ze tusim, ze array_diff_uassoc() je tedy napsane v perlu a htmlspecialchars() je v C (nebo obracene?).

Dalsi mozny problem je nedodrzovani konvenci v pojmenovani nekterych konstant ci promennych a na velikosti pismen _zalezi_ stejne, jako na podtrzitkach.

Nevynecham ani chaoticke (ne)objekty, co takto treba function __construct(); To je take pekna prasarna, proc nelze pouzit constructor jmeno, destructor jmeno ?

PHP je proste psane tak nejak bez vetsiho rozmyslu a nedava obcas smysl, nektere standardni ukony, predevsim v poli jsou neproveditelne beznym zpusobem (napr. vypsani prvniho znaku z pole myfield[] ze sloupce cislo 10 nelze provest pomoci echo myfield[]{10} ani pomoci echo myfield[{10}]; PHP je proto velmi nelogicky jazyk oproti kteremukoli neinterpretovanemu a verze 6 se zbytecne zameruje na nejaky UNICODE, ktery nikoho nepali, kdyz existuji spickove workaroundy (OpenSource knihovny).

Není to o tom, kdo tomu jak říká. Podpora Unicode znamená, že řetězcové funkce pracují s posloupnostmi unicodových znaků. V PHP tomu tak není. V jazycích, které podporují Unicode, se o kódování vůbec nemáte starat, maximálně až v poslední fázi, kdy se řetězec serializuje na výstup.

Nikdo tomu podpora Unicode neříká. To by muselo fungovat třeba tohle:

$string = '€';
echo $string[0];