Názory k článku
PHP konečně s podporou unicode

Doplním odkazy na techničtější informace, byť poněkud staršího data:

• Vývoj PHP 6
• na jakých místech se bude s kódováním pracovat

Tohle tady mělo být už mnohem dřív.

všem unicode podporuje nejenom recentní jazyky

A co se vám na tom nelíbí? Možná že se zde projevuje má náklonnost k biologii, ale i přesto si myslím, že není důvod toto slovo zde nepoužít.

súčasné jazyky

Nevim jak jste to myslel s tim demem, ale firefox, IE a asi i Opera mi rozhodne vsechny ty znaky neukazou, zalezi tedy na siri implementace UTF8?

Doufal jsem ze utf8 je bud implementovane nebo neni, ale ne neco na pul (nektere ty abecedy (znaky) neukaze (respektive misto nich jsou otazniky)

Ty otazniky znaci pouze to, ze nemate k dispozici font, ktery by obsahoval dane znaky jenz se maji zobrazit. Osobne by mne zajimalo zda vubec existuje nejaky pouzitelny unicode font se vsemi znaky...

Já vidím všechny znaky. Debianí balík msttcorefonts.

Lidem co rustinu/rakosnictinu neumi je to jedno, ale treba rakosnikum by vadilo, kdyby misto svych rakosnickych znaku meli otaznicky. Ale ti uz asi budou mit k dispozici vhodny font :)

Neviete odkial pochadza slovo "rakosnik", ja som hladal na nete ale nasiel som len nejakeho vtaka. Odkial sa tento pojem vzal a aky je jeho povodny vyznam?

ten rakosnik z vecernicku je rakosnicek. nicmene oboji je od slova rakos.

ok, ale aky je vyznam toho slova

Já bych tu viděl jistou xenofobní odsouzeníhodnou paralelu s larvami chrostíků, které si staví domečky z toho, co ulice (rozuměj: potok, řeka) dala, tedy z kamínků, písku, větévek atd. Říká se jim lidově rákosníci... Podobně poetická, politicky nekorektní možnost by tu byla opět z živočišné říše, tentokrát však z čeledi pěnicovitých...

Rákosník = trám (dřevěný), který slouží jako nosný prvek pro podhled z rákosu, na který se nanášela omítka. Standardní řešení dřevěných trámových stropů v domech do cca 1/2 20.stol.

tomu se rika xenofobie a leceni trva nekolik generaci

Nejenom. Vývojáři mozilly už několik let ignorují chyby s polovičatou podporou kombinujících znaků. A jsou jazyky, které se bez ní neobejdou.

Mě se taky vše zobrazilo správně. Mám nastavena písma z rodiny DejaVu.

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

Môj odkaz perlistom: http://ukazto.com/img/fuck_perl.jpg

tak tak, na webapps jedine Javu

assembler rulezzz, obzvlast na webove aplikacie

Fuj, jedine strojovy kod. C9

pisu v morseovce...

neni nad organicky vytvareni aplikaci..

a co bozska emanacia?

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

Aký editor odporúčate na PHP? Ja osobne preferujem technológiu ASP.NET a Visual Studio ale občas musím nakódiť aplikáciu v PHP(keď to požaduje zákazník), no chýba mi PHP IDE, ktoré by sa funkcionalitou približovalo Visual Studiu. skúšal som PHP plugin pre Eclipse a Zend Studio ale stále to nie je ono.

Já používám SciTE, ale to je jiná liga. Zend IDE a Eclipse jsou považovány za špičku, dobré reference jsou i na PhpED.

Bude to sice drsné, ale když se takovej vim správně nakonfiguruje, je to velmi slušné a hlavně velmi velmi rychlé IDE:
- doplňování jakýchkoli názvů, které se vyskytují v kódu (bohužel i těch špatných)
- obarvení dle syntaxe php (php funkce jsou zabarvené jinak než vlastní) + html
- strom vlastních funkcí i objektů s metodami v extra okně
- procházení souborů v extra okně
- skákání na definice funkcí (implicitně Alt+t, ale mám nastaveno i Alt+Enter)
- + prakticky co si vymyslíte, sám se chystám na debuging, neb existuje php rozšíření
pro dbg a s nim už zase vim umí kecat.

Existují i různé, ty komerční toho samozřejmě umí více ;)

bohuzel neumi, mame zakoupene licence na Zend - to je detska hracka. delam ve Vimu (kdyz uz musim kodovat v PHP)

K Visual Studiu je pro PHP projekt Phalanger. Už jsem ho stahl, ale eště nezkoušel.

Co se týče pluginu na vývoj PHP do eclipse, tak jsou vlastně dva - http://www.phpeclipse.de/ a potom projekt, který spadá pod Eclipse samotný - http://www.eclipse.org/pdt/
Nejdříve jsem dobu používat ten první, ale teď používám PDT a nemůžu si vynachválit.