Vlákno názorů k článku
PHP konečně s podporou unicode

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

Doplním pro ty, kteří se v PHP třeba tolik neorientují - PHP Unicode podporuje samozřejmě už roky - bez problémů lze vytvářet skripty v UTF-8 a ani práce s řetězci nečiní žádné potíže. Je potřeba ale používat některé z dostupných rozšíření.

PHP 6 bude mít podporu Unicode integrovanou a těsnější.

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.

Záleží na tom, jakou funkci použijete. Např. preg_* funkce podporují modifikátor u, který zapne podporu UTF-8. Více informací: Práce s UTF-8.

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.

Záleží na tom, čemu říkáte podpora Unicode.

• Lze vytvářet skripty v Unicodovém kódování? Ano, v UTF-8.
• Lze s řetězci pracovat podle toho, v jakém jsou kódování, třeba i vícebajtovém? Lze, pomocí knihoven iconv nebo mbstring

Já už tomu podpora říkám (byť volitelná), někdo ne. Koneckonců i v PHP 6 bude podpora nepovinná. To, že interní funkce PHP pracují s posloupností bajtů, je samozřejmě pravda.

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).

Přesně můj názor...

Pokud vám hosting nedá nejnovější verzi, přejděte na jiný. To je výhoda velké konkurence.

Povědomí o bezpečnosti je bohužel obecně nízké a netýká se to jen PHP (kde je problém lépe vidět kvůli spoustě začátečníků a amatérů a samozřejmě také některým nešťastným rysům jazyka - např. možnosti zapnout register_globals).

Nekonzistence názvů funkcí je problém vzniklý překotným počátečním vývojem PHP. Spíše než biflování bych doporučil dobrý editor, který s doplněním názvů funkcí pomůže.

Na velikosti písmen záleží i v jiných jazycích. Konstanty a proměnné jsou v PHP pojmenované konzistentně, proto se u nich velikost písmen rozlišuje. U funkcí (které byly v začátku převzaty z mnoha různých jazyků) se doporučují malá písmena, ale protože v různých jazycích je zvykem je psát různě, tak u nich na velikosti nezáleží.

V čem spatřujete prasárnu konstrukce __construct()?

Nevím, co máte na mysli pojmem "sloupec" u pole, ale pokud chcete získat první znak prvku s indexem 10, slouží k tomu $myfield[10][0] - dle mého zcela logická konstrukce.

Na získanie prvého znaku prvku s indexom 10 by som radšej použil substr($myfield[10],0,1), ale inak súhlasím. Programátorské prasiatka sa nájdu pri hociktorom jazyku, veľký podiel prípadov WTF v PHP je daný rozšírenosťou jazyka, a mýtom, že je vhodný pre začiatočníkov.

Suhlas.

PHP je krasny jazyk, lenze ma smolu v tom, ze aj on nejako zacinal, preto sa dopustil mnoha chyb.
Myslim, ze niekedy je zbytocne vysvetlovat tymto ludom, ze za vyvojom jazyka nestala nejaka velka skupina, ktora do neho lialia miliony korun, ale jednotlivec (jednotlivci) a ty sa dopustali chyb.

Ale som rad, ze sa snazi byt stale lepsim a lepsim jazykom. Len by som vsak uvital lepsie prepojenie OOP, nieco na styl Javy.

Nejen že se dopouštěli chyb, oni to prasili hlava nehlava, díky svému chybějícímu teoretickému vzdělání.

Bohužel jazyky založené na dokonalých a úplných teoretických základech se nelíbí skoro nikomu. Snad proto, že těch blbých, kteří tu eleganci nevidí, je většina. Viz Smalltalk & spol.

Ale to ze sa dopustali chyb by sme im mohli odpustit, jednalo sa len o proceduralnu cast PHP, objektovu cast spracovali dost pekne.

Len mi tam naozaj chyba nejaka poriadna sprava a previazanie tried.

Proste Java je ako OOP projektovana odzaciatku a aj podla toho vyzera. Kopec uzitocnych tried a metod dostupnych hned odzaciatku. Ak je PHP definovany ako scriptovaci jazyk tak mala mat podobnu filozofiu a dat odzaciatku dostupne vseobecne pouzitelne triedy alebo pomaly prepisovat urcite casti do objektov. Ako praca so subormi a pod. Jednoducho suborove funkcie obalit do nejkej triedy, ktora by poskytovala vacsi kompfort.

Na konstruktoru v PHP vlastne neni vubec nic spatneho (krome dvou podtrzitek). Za $myfield[10][0] dekuji, netusil jsem, ze slozene zavorky {} lze nahradit hranatymi zavorkami []

Python: __add__(self, parent) - tohle je teprve vec a nutnost volani self parametru je taky bozi zazrak. Stejne mam python, rad, uz aby nekdo poradne doklofal Ruby2.

Neblazni.

Ruby je syntaxov trosku taky exoticky tvor :)

Proc :) ?

Ruby ma moderni syntaxi, kazdopadne vylozene cistou a dokonale promyslenou. Ale pritom narozdil treba od Pythonu velmi flexibilni. Nestuzuju si :)

Ja som videl syntax Ruby, ale pre mna to nie je. Je to styl ala Pascal co nie je oja parketa. Radsej mam zlozene zatvroky, ktore su odzaciatku krasne zrozumitelne. Nejak sice "BEGIN" a "END" nemusim, no pri procedurach a trigeroch SQL jazyka sa im sice nevyhnem, ale aspon nejak :)

syntax Ruby je inšpirovaná skôr Basicom.

když se ti nelíbí end, používej {}

Presne tak, Ruby umoznuje ledacos, zavorky nejsou problem :)

Ja je sice moc nepouzivam, ale proti Gustovi ...

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];