Názory k článku
Jmenné prostory a další novinky v PHP 5.3

Pokud vím, tak SPL Types nejsou součástí PHP 5.3, ale jsou dostupné pouze jako PECL rozšíření.

jestli jsem to pochopil dobře, tak v příkladech článku jsou chybně použity ty dvojté dvojtečky, co byly v ostré verzi nahrazené lomítkem.

Je to použito jen v příkladu, který popisuje, jaké by s čtyřtečkou byly problémy. Zpětné lomítko se používá jen pro oddělení jmenných prostorů, statický přístup do třídy zůstal samozřejmě přes čtyřtečku.

tj. ty čtyřtečky v kapitole Late static binding jsou správně? (p.s. nejsem php programátor, takže to je jen dotaz abych pochopil co je jmenný prostor ;)

Ano jsou ;). Zde JE zamýšleno volání statické metody f třídy Potomek.

chcem poďakovať autorovi za výborný článok. php 5.3 bohužiaľ neprináša žiadne revolučné zmeny. inak zaujímalo by ma čo nové by mala priniesť verzia 6.0 ?

Žádné revoluční změny? Bez jmených prostorů a late static binding to bylo dosud k uzoufání.

a sú to revolučné zmeny? väčšina a jazykov obsahuje namespaces už od prvej verzie (napr.: C#) jediná zaujímavá zmena v PHP 5.3 sú anonymné funkcie. PHP by sa malo inšpirovať jazykmi ako ActionScript, alebo Ruby.

Jsou to revoluční změny v rámci php.

Mě tam to lomítko nesedí. Jsem zvyklej na tečku… …!…

Jako by nestačilo, že už teď dost lidí píše v PHP prasecky, ještě se přidá goto.. No super, tento příkaz tu opravdu chyběl :)

+1

Presne tak, ja som asi pred rokom v PHP riesil nejaky algoritmus a keby som vtedy mal k dispozicii prikaz goto, tak by sa dal napisat mozno o 70% jednoduchsie.

Můžeš pro zajímavost ten algoritmus uvést? Horko těžko jsem dával dohromady nějaký alespoň jakž takž smysluplný příklad na goto – moje myšlení s touto konstrukcí prostě není kompatibilní.

goto v jazyce jako je PHP? Když máme výjimky a cykly? Opravdu by mě zajímal jakýkoliv algoritmus, kde by goto vůbec k něčemu bylo.

V C je hlavně proto, že C nemá výjimky.

Samozrejmne ze v C lze pouzit strukturovane vyjimky.

„naruby“ nebo „na Ruby“? :)

OMG tak ted jsi me dostal! :-D

naprosty souhlas, uz se taky tesim az zas budu zachranovat nejaky takovyhle paskvil. Je ale pravda, ze i v Jave je neco podobneho. Skoda ze se to nepreklada do cestiny, to bychom mohli mit treba misto goto ano; jdi_do_riti:ano;

S GOTO jsem naposledy dělal v BASICu, možná ještě v PASCALu. Souhlasím se všemi, že GOTO je zastaralá věc a nemá v moderním kódu co dělat. Jenom to dovolí dělat špatným programátorům ještě horší kód.

Bohužel se začíná ukazovat nedostatečná odbornost vývojářů jazyka. Postupně z toho dělají opravdu šílený bastl. Ještě že už jsem z toho kolotoče pryč!

A ostatním doporučuji v rámci udržování znalostního portfolia zkusit alespoň python nebo ruby.

Chápu to samozřejmě jako nahrávku na flame :-).

Zpětných lomítek jsem se také děsil, ale dá se na to zvyknout velmi rychle a ve jmenných prostorech to vypadá nakonec docela přirozeně, subjektivně lépe než čtyřtečka.

Já jsem v Pythonu rok dělal a zas tak krásný mi ten jazyk nepřijde. Např. absence skutečně privátních proměnných je podle mě jasná chyba návrhu jazyka, některé věci se zase dělají podle mě zbytečně krkolomně.

A na Ruby se mi zase nelíbí, že dovoluje přepisovat metody.

V čem je (skutečný) problém absence privátních proměnných? Problém s public proměnýma je, pokud vím, ten, že po klientech třídy rozprskneš přímý přístup do paměti objektu – takže objekt nemá možnost reagovat. Pokud ale existuje možnost „obalení“ do properties, tak tento argument padá. To v pythonu (i v php) jde.

Co se týká kontejnerů, to je věc názoru, mě se míchání obyčejného a asociativního pole v php osobně nelíbí a nezdá se mi to o tolik složitější (ani pro začátečníky, spíš naopak).

Ty deskriptory jsou možná trochu složitější, ale jde to udělat i jinak

Jinak na pythonu oproti php oceňuji mimo jiné menší „psychologickou“ náročnost. Například nedávno jsem napsal něco takovýho: …array_map(arra­y(‚Sql‘, ‚q‘), $items)… 

Jinak pravda, právě s 5.3 několik silných argumentů v neprospěch php padá. Což je dobře. a říkal jsem si, kolik wtf bude, až to bude někdo číst. A pak jsem to pro zajímavost zkusil v pythonu:
map(Sql.q, items) Je to v podstatě stejné, ale když čtu něco podobného jako v té php variantě, tak mě to napřed vyleká (ok, jsem zbabělec). Podobně je to s tím, když se používá jen . (tečka) versus :: \ → (což je teda opačný případ k tomu array() versus [] {})

Jinak, uznávám, právě s php 5.3 několik silných argumentů v neprospěch php padá. Což je dobře.

A jé to tlačítko zobrazit náhled funguje :(

Věta

Jinak pravda, právě s 5.3 několik silných argumentů v neprospěch php padá. Což je dobře.

se mi omylem dostala i doprostřed příspěvku (srovnání map a array_map)

„Např. absence skutečně privátních proměnných je podle mě jasná chyba návrhu jazyka“

Huuu? Co to jsou privátní proměnné? Lokální proměnné funkcí? K těm je přístup jen uvnitř jejich scopu. Já bnýt programátor v PHP, tak se soudy o „jasných chybách návrhu jiných jazyků“ značně šetřím. Mnohé z nich byly skutečně navržené. Python má sice nedostatky, ale ty jsou aspoň soustavně opravovány.

„A na Ruby se mi zase nelíbí, že dovoluje přepisovat metody.“

No tak v tom případě musíme Common Lisp, Scheme (R5RS), Smalltalk a asi dva tucty dalších jazyků zahodit do koše jako ouplně nepoužitelné.

Víte, co by Vám na to řekli autoři jazyka Lua? „If you don't want to do something, just don't do it.“

Co se privátních proměnných týče, tak jako vývojář knihovny nechci, aby mi k ní uživatelé přistupovali jinak než přes veřejné API. Samozřejmě, že když se tím nebudou řídit, tak to bude jejich chyba, ale vysvětlujte jim to pořád dokola.

A co se přepisu metod týče, tak to naráží v situaci, kdy se dvě knihovny rozhodnou přepsat stejnou metodu a já chci použít obě. Třeba Rails by se dalo těžko použít s jinou knihovnou, která by přepisovala stejné metody.

Mantra „If you don't want to do something, just don't do it.“ se bohužel dá použít jen v situaci, kdy všichni vývojáři hrají na stejné straně. Při vývoji knihoven to je ale tak, že musím respektovat ostatní knihovny a někdy bojovat s uživateli.

Ok, uznávám, že na tvých argumentech něco je.

Pokud potřebuješ privátní proměnné chránit před útočnými nájezdy hloupých kolegů, tak chápu, že by se ti opravdu privátní proměnné líbily. Já v praxi nic takového nepotřebuji, protože moji kolegové prostě umí v Pythonu programovat. Kdyby programovat neuměli, nepomůže nic.

Třídy ze standardní pythoní knihovny s touto vlastností taky žijí. A rozhodně se s nimi pracuje líp než s tím nekonzistentním hnojem co má v základu PHP.

Velká výhoda Pythonu je v tom, že umožňuje odložit řízení přístupu k datům „na potom“. V Javě když uděláš proměnnou public, tak už ji nikdy nebudeš kontrolovat (leda by jsi změnil rozhraní). Proto jsou javovské programy plné nicnedělajících a zbytečných getterů-setterů. V Pythonu můžeš veřejnou proměnnou vždycky obalit a mít ji pod kontrolou.

PHP má v možnostech řízení přístupu stejnou výhodu. K původně veřejné vlastnosti si kdykoliv později mohu dodělat getter a setter, přičemž zvenku se s ní pracuje pořád stejně. Pokud v tom má člověk systém (např. ten, že metody pojmenovává getWidth a setWidth), tak se to dá navíc zautomatizovat.

Takze nakonec to dopada tak, ze vsechny vlastnosti tridy jsou private a nad to se posadi globalni __get a __set, ktery vsechny ty „prekrasny“ private elegantne zrusi :) Hlavne ze se to tvari „zapouzdrene“. Ale to neni jen o slove private, protected a public, to je o spravnem navrhu trid. A zpetne lomitko to „programatory“ v php nenauci.

Co se mi ale libi, jsou inline funkce, ze by konecne nabeh na pouzitelnou lambda fci?

V tom případě by byly stejně out i set/get přístupové metody – nesprávný návrh tříd?

Python má pseudoprivátní proměnné, kterými říkáte, že by se neměly používat. Ale obcházet encapsulation prase dokáže např. i v C++: #define private public ;)

Nic, David Grudl zase dělá chytrého. Toho si nevšímejte.

A Common Lisp. A nestatické implementace Scheme. A dva tucty dalších jazyků… :]

Python má stabilní větev 2.x a stabilní větev 3.x. Můžete klidně zůstat na 2.x, která bude udržována i do budoucna, a užívat si backporty těch změn, které nezpůsobí zpětnou nekompatibilitu.

Ruby znakový typ nemá, stejně jako Python. Pouze ve verzi 1.9 přešlo Ruby na tentýž komcept, jaký je v Pythonu, a sice že „znak“ je řetězec délky 1. Autor Ruby není Unicode-hater, ale m17n-lover. Řetězce v Ruby 1.9 podporují m17n.

Možnost rozšířit libovolnou třídu byla převzata ze Smalltalku a (Common) Lispu. Stejně tak si můžete zajít do kuchyně pro nůž a zkusit, co se stane, když si ho probodnete hrudníkem, ale většina lidí to nedělá o nic častěji, než Smalltalkeři předefinovávají ifTrue: a ifFalse: metody (má to samozřejmě pedagogickou hodnotu ;-)). V Common Lispu je tuto fíčuru nutné odemknout, protože balík CL je defaultně zamknutý, ale vývojářům se tím usnadňuje a urychluje vývoj samotné platformy – můžou měnit a ladit kód standardních knihoven a ihned ho zkoušet s „ostrými daty“ bez větších prodlev.

Jak jsem poznamenal výše, vývojáři jazyka Lua k podobným tzv. „nedostatkům“ poznamenali: „If you don't want to do it, just don't do it.“

Vyčítat Pythonu stabilitu při srovnání s PHP je fakt důmyslné. PHP rozbíjelo aplikace i při desetinkových (nebo i setinkových?) updatech. Zatímco Python má po X letech nekompatibilní, jasně definované pokračování s nástroji a návody pro přechod.

Rozdíl je ten, že v Pythonu to je záměr a v PHP chyba :-).

a to jste jeste nevideli jak vypada vykonna cast Zend Engine. Je totiz z goto kompletne sestavena.

„Byla odsraněna konfigurační direktiva…“ :D

„Na rozdíl od JavaScriptu ale nejsou vidět všechny proměnné, nýbrž jen ty, které explicitně uvedeme v klauzuli use“

Spíš na rozdíl od snad všech programovacích jazyků s lexikálním scopingem, ne? ;-) No jo, PHP zase musí mít něco extra. :]

… flex neni parser ;-)

Samozřejmě, Flex je ušlápnutý český programovací jazyk, který nikdo nechce. :]

Děkuji za upřesnění. Flex je program pro lexikální analýzu, který je parserem využíván. V článku jsem se dopustil určitého zjednodušení.

No a pak je to taky flashový framework, ale to je jen shoda jmen…

Flex je program pro lexikální analýzu

tesne vedle… flex je generator lexikalnich analyzatoru! sveho casu o tom na rootu vysly i najeke clanky…

Podla mna cely ten uspech PHP stoji a pada na free hostingoch. Rovnako ako to bolo pri mysql, dnes sa uz daju najst aj s postgresom. Na rozne osobne blogy, alebo jednoduche CMSka nie je PHP zla volba, ale clovek by chcel skusit nieco ine a 0 bodov a kodit len tak pre zabavu sa mi zrovna nechce.
Existuju vobec free hostingy s pythonom (alebo niecim inym)? Nasiel som 3 a maju rozne obmedzenia – stranky po anglicky, prispievanie na forum (navyse po podrobnom badani je to ten isty poskytovatel)..

ps: k clanku som sa preklikal od inej stranky a nejako ma nenapadlo, ze je rok stary, ale otazka stale trva :)