Nejpodivnější error hláška v PHP

28.2.2009 20:51 | Přečteno: 1633× | Programování

Právě jsem při programování bc práce narazil na docela zvláštní hlášku v PHPku. Protože jsem ještě podivnějsí hlášku neviděl, tak jsem se rozhodnul jí zde postnout

Při pokusu o něco takového:

$this->_db=$dbtype::getInstance($table,$key);

mi PHPko vypsalo něco takového:

Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM in /srv/www/spu/libs/application/database.php on line 18

Co tím nerozluštitelným řetězcem kdo chtěl říct o této chybě mi zůstává záhadou :O Pro upřesnění dodávám, že mám PHPko zkompilované s podporou patche Suhosin v Gentoo.

Narazili jste taky na nějakou podobně nesrozumitelnou hlášku?

       

Komentáře

[helb]

To jsou ty dvojtečky... wikipedia

[Lijec]

Stacilo to dat do googlu-uz sem o tom nekdo psal. Trapne bejcku, trapne jak svin.

[Luk]

Tady je krásně vidět, proč se při pojmenovávání identifikátorů v programech raději držet angličtiny

[frEon]

Tak za tohle uz sem taky nekoho proklel.

[AraxoN]

jj, toto som už videl viackrát... nakoniec sa vždy ukázalo, že sa niekde do kódu vlúdili znaky, ktoré tam byť nemali

[Miloslav Ponkrác]

Podobné hlášení se vyskytuje docela často, tedy pokud svátečně neprogramujete, pak to pro Vás může být nové a zajímavé.

PHP rozparsuje zdrojový kód do proudu tokenů, které jsou nazvány výčtovým typem, jehož jedné hodnotě v chybovém výpisu se právě divíte. Kdybyste byl zběhlý v PHP víte, že tento parser je dokonce dostupný i programátorovi v PHP, takže hodnoty můžete najít přímo v oficiálním manuálu PHP.

Jestli se budete divit každé podobné hlášce (nejen v PHP), tak to budete mít asi plný život údivů a překvapení. Hláška je ok, je srozumitelná a jasná.

[Ladicek]

Nevěděl jsem, že umíte hebrejsky Což bych viděl jako nutnou podmínku k tomu, aby typ tokenu T_PAAMAYIM_NEKUDOTAYIM byl srozumitelný a jasný. Ale máte pravdu, divit se tomu je scestné, je to přece PHP.

[Miloslav Ponkrác]

Mě ani nenapadlo, že je to hebrejsky, stejně tak to může být zkratka z mnoha slov. Nicméně každý, komu něco říká slovo výčtový typ, by asi pochopil o co jde. Identifikátor až tak podstatný není.

Pokud někdy něco více naprogramujete v setkání s více programátory, tak se často setkáte s identifikátory, kterým ně vždy budete rozumět. Ale budete chápat smysl a to se v případě této chybové hlášky dá velice snadno.

Jinak názvy všech konstant výčtového typu tokenů najdete zde:

http://cz.php.net/tokens

Schválně, představte se, že nevíte nic o unixu, ani Linuxu (třeba jste se nesetkal s UNixem/Linuxem a třeba znáte dokonale anglicky) a řekněte mi, jaký je význam těchto programů: awk, bash? Asi je to stejně pochopitelné jako ta hebrejština. To prostě nevymyslíte. A pak někdo narazí na nesrozumitelný identifikátor a dělá z toho osmý div světa. Jako vývojář a nejen vývojář narazíte na tisíce nesrozumitelných identifikátorů, jejichž přesný význam není hned jasný, to je celé.

[Michal Kubeček]

To je sice hezké, ale

• když už má identifikátor návodné jméno, u mezinárodního projektu by mělo být v angličtině
• jde-li o jméno, které je vidět "ven", platí to dvojnásob

[Miloslav Ponkrác]

Ono by mělo být věcí

Identifikátor chyby nemusí mít návodné jméno. Když se budu bavit o identifikátorech chyby, která jsou vidět ven: Schválně, co znamená chyba kompilátoru C4013? (MS Visual C/C++), nebo chyba číslo 1001 (MySQL)? Co znamená SQL error: HY001? (standardizovaná identifikace chyb v SQL databázích).

Jinak třeba OpenOffice má problémy shánět vývojáře také proto (kromě nutné byrokracie se Sunem), že řada kódu, názvu funkcí apod.. je v němčině.

Problém je, že někdy také nemusíte tušit, že Váš projekt bude mezinárodní, a druhak také to, že nemusíte tušít, že Váš identifikátor proleze ven (třeba později).

Zkrátka až najdete něco dokonalého, dejte vědět. Já neznám jediný sw projekt, na kterém by nebylo co kritizovat, a který by měl dokonale čistý kód.

 

[Martin Mareš]

Identifikátor chyby nemusí mít návodné jméno.

Jistě nemusí, alespoň v tom smyslu, že když nemá, nenastane konec světa ani spor v teorii množin. Ovšem identifikovat chyby neintuitivními identifikátory má svůj smysl leda tehdy, když zařízení umí hlásit chybu dvoumístným displejem nebo blikáním jedinou LEDkou, v ostatních případech je to prasečina, za kterou by se mělo věšet za uši do průvanu.

[Miloslav Ponkrác]

Ano ano, souhlasím.

Nicméně žádný program není dokonale proveden. Až se tak stane, bude to někdy v době, kdy lidstvo už dávno bude mít kolonizovanou celou galaxii a několik přilehlých.

[Miloslav Ponkrác]

Jinak když už jsme u toho, tohle je právě obrovská nevýhoda programování v jazyce C a jedna z věcí, proč nechci programovat v jazyce C.

Všechny identifikátory v C jsou veřejné a v jenom globálním prostoru jmen. Neexistují tam ani třídy, ani prostory jmen, takže musíte vždy řešit konflikty jmen s jinými části projektu. Z toho důvodu občas řada C programátorů rezignuje a hledá vhodné, nekonfliktní jméno identifikátoru, a velmi často se z tohoto důvodu v C použije mateřština programátora. Je jasné, že hebrejský název má minimální pravdděpodobnost, že bude kolidovat s jakýmkoli anglickým identifikátorem v projektu.

Chcete-li si podobné problémy ušetřit, používejte schopné programovací jazyky, které mají základní prostředky pro spolupráci více lidí. Jedním z nich je podpora prostorů jmen, a necpání všeho do jednoho globálního prostoru.

Zdaleka nevidím poprvé, že programátoři v C v týmovém projektu použili svůj národní jazyk, protože řešili právě konflikty identifikátorů. Jazyk C je velmi nevhodný pro větší projekt a občas donutí i trpělivé lidi prasit.

[frEon]

Všechny identifikátory v C jsou veřejné a v jenom globálním prostoru jmen. Neexistují tam ani třídy, ani prostory jmen, takže musíte vždy řešit konflikty jmen s jinými části projektu. Z toho důvodu občas řada C programátorů rezignuje a hledá vhodné, nekonfliktní jméno identifikátoru, a velmi často se z tohoto důvodu v C použije mateřština programátora. Je jasné, že hebrejský název má minimální pravdděpodobnost, že bude kolidovat s jakýmkoli anglickým identifikátorem v projektu.

Nevidim nejmensi duvod, proc me, jako uzivatele by mel program otravovat se svoji vnitrni reprezentaci sveho stavu. Me je jedno, ze rozseka text na nejake kousky a k nim ma nejakej vyctovej typ, s kterym ty kousky prevadi na cisla... Pro me, jako uzivatele php je dulezity, ze tam mam navic ctyrtecku.

[Miloslav Ponkrác]

„Nevidim nejmensi duvod, proc me, jako uzivatele by mel program otravovat se svoji vnitrni reprezentaci sveho stavu.“

Pokud nebudete mít chybu v syntaxi ani v programu, tak to program nebude dělat.

„Me je jedno, ze rozseka text na nejake kousky a k nim ma nejakej vyctovej typ, s kterym ty kousky prevadi na cisla... Pro me, jako uzivatele php je dulezity, ze tam mam navic ctyrtecku.“

Uživatel PHP se zove programátor a jako takový nemůže být odstíněn od vnitřní reprezentace svého nástroje. Zvláště, když dělá chyby.

[frEon]

Uživatel PHP se zove programátor a jako takový nemůže být odstíněn od vnitřní reprezentace svého nástroje. Zvláště, když dělá chyby.

Nesouhlasim. Abych mohl programovat v c++ nepotrebuju vedet jak presne ktery kompilator uchovava a zpracovava ctyrtecku. Dulezity pro me je co to znamena, kdyz ji do kodu napisu.

Myslim, ze se shodnem, ze nejaka trida je taky programatoruv nastroj. jeji instance, ma nejake metody, pomoci nichz ovlivnuje stav objektu aniz by potreboval vedet, jak a cim je ten stav toho objektu reprezentovat uvnitr. Myslim, ze se tomu rika zapouzdreni...

[Martin Mareš]

Všechny identifikátory v C jsou veřejné a v jenom globálním prostoru jmen.

Namespacy jsou příjemná věc, ale nijak hluboká. Není žádný zásadní rozdíl mezi tím, když identifikátor nadeklarujete v namespacu XYZ, a tím, že mu přidáte prefix "XYZ_". Namespacy vám pouze ušetří trochu psaní.

Daleko zásadnější záležitost je viditelnost symbolů (například ven z dynamických knihoven), tu bohužel rozumně neřeší žádný mně známý jazyk.

[Miloslav Ponkrác]

Žádný vyšší programovací jazyk není nic jiného, než syntaktický cukt na strojákem, když to vezmete do důsledků.

Za žádnými syntaktickými věcmi nestojí žádná hluboká myšlenka a jistě vše jde obejít.

Zásadní rozdíl v prefixu sice není, ale v praxi dost podstatný. Jednak zdroják s namespaces bude čitelnější a udržovatelnější. Jednak nemůžete v praxi zavést konvenci, že identifikátory XYZ_ budete používat jen Vy, protože nemáte dohodu se všemi autory knihoven a kódu. A také délka identifikátoru je v C omezena – na 32 znaků. Takže se moc nerozšoupnete, když budete ve větším týmu. Některé kompilátory C mají toto omezení dokonce na 6 znaků, proto jsou také názvy knihovních funkcí a Unix API tak krátké. Třeba strlen, mmap, atd..

[Martin Mareš]

Stejně tak nemáte zaručeno, že váš namespace nebude používat nikdo jiný na světě.

[Miloslav Ponkrác]

Pravděpodobnost konfliktů je naprosto minimální, pokud trochu přemýšlíte. Já viděl tisíce konfliktů jmen v C, ale ani jeden v C++ s namespace.

Někteří programátoři používají jako namespace webovou adresu svých stránek (obvyklé třeba v Javě).

[Martin Mareš]

Možná je to tím, že ekosystém programů napsaných v C je nesrovnatelně bohatší než těch, které byly napsány v C++ v té poměrně krátké době, co tento jazyk umí namespacy.

Mimochodem, ani "webová adresa" není identifikátor, který by s časem nemohl měnit význam.

Také velmi snadno nastanou problémy s kusy kódu, které mají společnou historii. Která vývojová větev si má ponechat původní namespace?

Kdepak, ani namespacy nejsou zázračným lékem, který nás osvobodí od problémů s jednoznačností jmen. Ale pomoci od některých z nich mohou.

[Miloslav Ponkrác]

A co mi tu vlastně chcete dokázat? Že věc, která řeší 99,999% problémů, které C neřeší vůbec a dlabe na to, a ta věc se jmenuje namespace, je špatná, protože neřeší 100% problémů?

[Martin Mareš]

To, že si můžete připisovat devítky k procentům, jak chcete, ale realitu tím neovlivníte

Realita je taková, že jak ve slušně udržovaných Céčkových i C++kových programech konflikty nastávají s poměrně nízkou, leč nenulovou pravděpodobností. Naproti tomu v mizerně udržovaných programech nastává téméř cokoliv. Jinými slovy namespacy jsou drobná užitečná featurka, ale nic úžasného.

[Martin Mareš]

Žádný vyšší programovací jazyk není nic jiného, než syntaktický cukt na strojákem, když to vezmete do důsledků.

To je hluboce zažitý omyl, omluvitelný snad jedině malým rozhledem po tom, jak může vyšší programovací jazyk vypadat. U C/C++ většina featur opravdu je pouhý syntaktický cukr, ale existují i jazyky, které mají daleko bohatší sémantiku: v mnoha funkcionálních jazycích například najdete funkce vyšších řádů nebo líné vyhodnocování. To už není jen cukřík.

[petr_p]

$ cat test.c 
static void my_identifier_static(void) {}
void my_identifier_nonstatic(void) {}

$ gcc -fPIC -DPIC -shared -o test.so test.c

$ nm -D test.so 
         w _Jv_RegisterClasses
00002010 A __bss_start
         w __cxa_finalize
         w __gmon_start__
00002010 A _edata
00002014 A _end
00000464 T _fini
00000300 T _init
00000421 T my_identifier_nonstatic

[Michal Kubeček]

Hm... já tipoval finštinu... :-)

[xxxs]

ja estoncinu.

[CET]

Ja madarstinu:) Zrovna nedavno jsem to taky videl, chyba byla v tom, ze jsem nemel do PHPcka nainstalovanej modul memcache a ono se to asi snazilo volat neexistujici metodu nebo vytvaret objekt neexisujici tridy.