Vlákno názorů k článku Jmenné prostory a další novinky v PHP 5.3 od Martin Soušek - Bohužel se začíná ukazovat nedostatečná odbornost vývojářů jazyka. Postupně...
-
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.
-
ivand (neregistrovaný)
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(array(‚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)Jinak, uznávám, právě s php 5.3 několik silných argumentů v neprospěch php padá. Což je dobře.
-
povinná (neregistrovaný)
„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.
-
Alblaho (neregistrovaný)
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á
getWidthasetWidth), tak se to dá navíc zautomatizovat. -
soda (neregistrovaný)
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?
-
Na PHP (a stejně tak i Ruby nebo Pythonu) je vidět nedostatečná odbornost vývojářů v oboru „návrh počítačového jazyka“. To je bez debat.
Ale co s tím? Přestat tyto jazyky používat? Přestat programovat? Nebo uspořádat finanční sbírku a zaplatit si Anderse Hejlsberga, aby pro LAMP navrhl lepší jazyk, třeba vycházející z nějakého výše uvedeného? Asi by to bylo nejlepší, ale je to utopie.
-
Python je krásný jazyk, má jen takový drobný problém, že autor si mění syntaxi a nutí přepisovat programy.
V PHP nikdy tak tvrdá změna v syntaxi jazyka, jako v Pythonu nenastala. Je naprosto jedno, jaký je Python jazyk, když zpětná kompatibilita je pro pythonisty sprosté slovo a snaží se to prakticky dokázat.
Ruby je na tom stejně, ale s tím, že řada věcí je tam dosti všelijaká. Například Ruby je snad jediný jazyk, který až do verze 1.9 neměl znakový typ. Autor Ruby nesnáší Unicode. Možnost rozšířit kdykoli definici jakékoli třídy kýmkoli, dokonce i systémové v core jazyka.
-
povinná (neregistrovaný)
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.“
