Starší komentáře ke článku: Vývoj PHP - cesta správným směrem?
Zpět na článek | Úvodní stránka Interval.cz
Datum vložení: 24.1.2005 1:54:09
v obecné rovině s autorem souhlasím. Také si myslím, že robustnost objektového modelu předběhla schopnosti PHP a jakoby svádí k tvorbě aplikací, na které PHP nemá. Osobně považuji PHP5 za takový "service pack" pro PHP4, neboť opravuje zásadní chybu čtverky - nutnost před každou objektovou proměnnou psát &
OBJEKTY
Nicméně přes úvodní slova považuji rozšíření objektového modelu PHP za dobrou věc. Výhradně. Přinejmenším proto, že ukáže všem "neobjektovým programátorům" směr, který by se měli už konečně naučit. Vlastně do přečtení tohoto článku jsem nevěděl o nikom, kdo by rozšíření považoval za zápor :-) A vidím tu i příležitost, jak se zbavit jedné, v článku zmíněné, neřesti.
NEJEDNOTNÉ POJMENOVÁNÍ
Nedodržování zásad pojmenování funkcí, metod a objektů je cena, kterou PHP zaplatilo za svůj bouřlivý vývoj a bohatství knihoven, kterými disponuje. Není však možné tento problém vyřešit radikálně a naráz půlku funkcí přejmenovat. Očekávám(-kával jsem), že s postupným přechodem na objekty se toto časem vyřeší - tedy objektové verze knihoven budou mít už jednotnou konvenci a neobjektové funkce v dalších verzích vymizí. V tomto směru je samozřejmě mysqli vs. SPL zklamáním.
NETYPOVOST
Označení PHP za ryze netypový je nesmysl. Už proto, že PHP disponuje celou řadou funkcní a konstrukcí, které umí s typy pracovat. Není sice možné definovat typ vlastní, nicméně tento nedostatek z velké části řeší objekty a tvárnost standardních typů. Zkrátka mezi jazykem, který provádí automatické přetypování a jazykem netypovým vidím zásadní rozdíl.
ŽIVOTNOST OBJEKTŮ
Plýtvání strojovým časem a pamětí jde ruku v ruce s pohodlím (pohodlností) programátorů. O tom by se dal napsat samostatný článek, který by začínal vyprávěním o assembleru a skvělém tabulkovém procesoru Lotus 1-2-3, který měl 300kB včetně ovladače pro tiskárnu, pokračoval tím, že svého času bylo Pentium 160MHz děsný dělo a samozřejmě na něm perfektně fungoval PhotoShop a Corel a MS Office a končil zamyšlením, proč dnes chce instalace driverů k tiskárně HP minimálně 375MB místa na disku a proč si kousne tolik paměti a procesoru, že je na onom Pentiu 160MHz nepoužitelná.
Pardon - hodně jsem odbočil. Chtěl jsem jen říct, že nároky SW na HW se zvyšují rychlejí, jeho funkčnost. Objekty v PHP představují ono pohodlí programátora. Pohodlí znamená větší režii. Neviděl bych v tom problém, ani důvod se objektům vyhýbat. Za skutečné brzdy aplikací považuju spíš chybějící indexy v databázích nebo špatně navržené algoritmy.
Mimochodem, s tou životností objektů by se dalo jistě zajímavě experimentovat, například využitím sdílené paměti (<a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://interval.cz/clanek.asp?article=3749)' target='_blank'>http://interval.cz/clanek.asp?article=3749)</a>. Samozřejmě to není nic pro freehosting s PHP :-)
VÝJIMKY & UNICODE
Souhlasím, že zpracování výjimek vypadá spíš jako ukázka toho, co jednou bude umět PHP6. Autoři zřejmě k dokončení tohoto úkolu potřebují feedback od programátorů, tak přišli s polotovarem. Nic však neomlouvá laxní přístup k podpoře Unicode. To je zásadní nedostatek PHP.
Datum vložení: 24.1.2005 10:26:46
A jaký jazyk je podle Vás netypový? Každý jazyk přece musí podporovat datové typy, přinejhorším skrytě. Typový jazyk ale nutí programátora uvádět typ u každé proměnné nebo parametru. A pak provádí při kompilaci (nebo interpretaci) typovou kontrolu. A typová kontrola je podlě mě hodně dobrá věc. Pokud píšu nějakou funkci s parametrem, ve kterém očekávám číslo, přece bych rád zabránil situaci, že by se mi tam dostal řetězec. Tohle PHP chybí, proto PHP zůstane netypovám jazykem určeným pro jednoduché aplikace.
Datum vložení: 24.1.2005 15:55:30
A je snad problém otestovat si proměnnou pomocí is_int()/is_numeric() popř. ji zkonvertovat na číslo?
To že to většina lidí nedělá není problém jazyka ale těch lidí. Koneckonců argument, že je to problém PHP je zcestný, identickým problémem trpí stovky aplikací napsaných ve všem možném i nemožném (slavný Portál veřejné správy nevyjímaje).
Datum vložení: 24.1.2005 17:57:10
To je asi nějaký vtip? To si má programátor na začátku každé funkce kontrolovat, jestli jsou parametry správného datového typu? Proč by to nemohl dělat kompilátor? Já netypovost za problém považuji, a ano, je to problém PHP, ačkoli PHP není jediný jazyk, který tento problém má. Pracoval jste někdy vůbec s důsledně typovým jazykem?
Datum vložení: 24.1.2005 19:20:44
S důsledně typovým jazykem jsem pracoval 21let. V PHP tvořím asi 6 let. Tento nepoměr považuji za velkou výhodu. Protože "typovost" mám zažitou v krvi, můžu si vychutnat výhody netypovosti a zároveň být ostražitý v okamžiku, kdy se z výhody stává nevýhoda.
Nicméně svou větou <I>"To si má programátor na začátku každé funkce kontrolovat, jestli jsou parametry správného datového typu?"</I> jste vlastně mimoděk potvrdil původní námitku, že PHP je typový jazyk :-)
<I>"Proč by to nemohl dělat kompilátor?"</I> protože PHP kompilátor nemá. Koneckonců, napsat kompilátor pro skriptovaný jazyk nelze.
Datum vložení: 25.1.2005 10:29:41
ad1. Otázka byla pro Marabu (nevím jak to skloňovat ;)) Jaké jsou výhody netypovosti? Jasně že programátor je lenivý, takže nemusí přemýšlet, s jakými datovými typy se vlastně potýká. Vystavuje se ale riziku zanášení chyb a vzniku nepředvídatelných situací za určitých okolností. Sice je např. možné napsat fci, která na vstupu přijme např. číslo i řetězec, to je ale jinde řešitelné např. přetěžováním. Pokud se v mém kódu bude někdo hrabat, bude v typovém jazyku vždy vědět, jaký typ se ukrývá ve které proměnné atd... Tyto "drobnosti" jsou důležité pro velké projekty, ale mohou způsobit problémy i v malých. Neumím si představit, že bych v nějakém netypovém jazyce spravoval projekt s řádově desetitisíci řádky zdrojového kódu.
ad2. Přečtěte si druhý přízpěvek v tomto threadu. Nebudu to psát znova...
ad3. Proč by nešlo?
Datum vložení: 4.2.2005 20:41:09
Ale lze. Viz Phalanger na <a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://php-compiler.net' target='_blank'>http://php-compiler.net</a>.
Datum vložení: 23.4.2006 12:22:52
Máme rok 2006 a kompilátor pro PHP uz existuje =) To ale vyvoj http://www.php-compiler.net/
Datum vložení: 25.1.2005 9:56:02
Programátor tak jako tak na začátku většiny funkcí testovat parametry musí (dělíte snad rád nulou?), pokud to nedělá, je to spíš bastlíř než programátor. Jedna kontrola navíc (popř. přetypování pokud je vhodnější) nikoho nezabije. Nebo vám snad připadá jako vhodné ukončení aplikace například toto? <a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://www.zive.cz/poradna/SubChild.asp?Qst=a&Main=57' target='_blank'>http://www.zive.cz/poradna/SubChild.asp?Qst=a&Main=57</a> popř. <a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://www.zive.cz/poradna/SubChild.asp?Qst=2+2&Main=57?' target='_blank'>http://www.zive.cz/poradna/SubChild.asp?Qst=2+2&Main=57?</a> Zřejmě pan autor nepočítal, že v parametru Qst může přijít i něco jiného než číslo.
Polovina argumentů o striktně typových jazycích je často a jen o tom, že lidé nesnáší ošetřování neobvyklých situací - a spolehnou se radši na to, že jejich aplikace zkolabuje sama, než aby si preventivně něco testovali. Apropo, z hlediska internetových aplikací je netypovost daleko výhodnější než u klasických - protože k parametrům v URL či k přijatým parametrům se ani nelze chovat jinak, než že se jedná o string (popř. pole). To, že PHP není striktně typové, lze jistě považovat za jeho nevýhodu pokud na to není člověk zvyklý. Pokud si ale navyknete na pár základních pravidel o konverzích typů v PHP, lze to obratem využít jako výhodu...
Ano, ve striktně typovém jazyce jsem také programoval. Moc velký rozdíl v tom nevidím. Pravda, spousta příkazů vypadala jinak a spousta věcí fungovala jinak - ale o tom už je život, že se přizpůsobujete změnám, ne?
Datum vložení: 25.1.2005 10:44:32
Uvedl jste krásný příklad, ještě že jsem to nepsal já, jinak bych se hanbou propadl ;) Teď vážně. Tyto situace opravdu není nutné kontrolovat a ošetřovat. V moderních jazycích je to zbytečné. Necháme klidně vyvolat vyjímku. Máme bloky try ... catch, a chybu ošetříme tam, kde ji ošetřit můžeme.
Představte si, že máme např. funkci, která má parametr s ID článku (je jedno, jestli string nebo int), a ta nám má vrátit obsah článku z databáze. Řekněme že vy byste tam ten parametr nějak ošetřil. Ale co uděláte, když se stane nějaká chyba? Vrátíte null, a budete tento stav opět ošetřovat o úroveň výš? Děkuji, nechci. Já raději tu vyjímku nechám prohučet až do místa, kde vypisuju článek, a tam vytvořím blok try ... catch, a do catch napíšu na výstup "Článek nelze najít." Ošetřím tak všechny situace, na které jste Vy zapomněl, ušetřil jsem si hromadu práce, a řádků zdrojového kódu, který je díky tomu přehlednější... a tohle je moderní programování, které známe v .NETu a Javě.
Datum vložení: 25.1.2005 19:40:18
No to snad nemyslite vazne? Vyjimky mame z duvodu programovaciho prostredi pro pripad, ktery nelze dopredu osetrit (napr. otevreni spojeni, to nezjistite, jestli muzete, nebo ne, proste to musite zkusit), nikoliv z duvodu lenosti programatora... Pokud by se mi zamestnacec, nebo student pokusil proste resit napr. deleni nulou tim, ze si dany blok zavre do vyjimky, hnal bych ho.
Datum vložení: 25.1.2005 23:39:06
Dělení nulou je typicky školní příklad chybné operace ;) Asi jsem se nevyjádřil moc jasně. Do bloku try obvykle neumisťujeme konkrétní místo výskytu chyby, ale blok, jehož případnou chybu můžeme na daném místě ošetřit. Tedy např. jak jsem psal, mějme zjednodušený kód pro výpis článku z db (C#):
protected string DejClanek (int ID)
{
... tady jsou operace, které mohou vyvolat vyjímku
}
public void PisClanek (string ID)
{
try
{
Response.Write (DejClanek(int.Parse(ID)));
}
catch
{
Response.Write ("Článek nelze zobrazit!");
}
}
Funkce PisClanek nevrací žádnou hodnotu, a lze předpokládat, že nikoho, kdo ji volá, nemusí zajímat, jestli byl článek skutečně zobrazen, nebo ne. Zato funkce DejClanek musí vždy něco vrátit, volající kód očekává návratovou hodnotu, a chybová hláška místo textu článku pro něj nemusí být akceptovatelná. Proto je lepší, když přímo vyvolá vyjímku. Všimněte si, že nemusím ošetřovat vůbec chybové stavy, pokud se ovšem na nějaké konkrétní nechci přímo zaměřit. Jaké stavy to jsou? Např. nelze převést řetězec na integer, nepodaří se spojení s DB, článek se zadaným ID neexistuje... apod. Ještě k tomu připojení k DB - samozřejmě je třeba zajistit jeho uzavření v každém případě, a to takto
SqlConnection conn = new SqlConnection (connstr);
conn.Open();
try {
... nějaké operace
}
finally {
conn.Close();
}
nebo lze také trochu elegantněji:
using (SqlConnection conn = new SqlConnection (connstr))
{
conn.Open();
.... nějaké operace
}
A tento přístup je jistě mnohem elegantnější a čistší, než křečovitě odhalovat všechny možné vyjímky v místě vzniku, kde je stejně nelze správně ošetřit:
try {
conn.Open();
}
catch {
... nějaké ošetření
... no to by mě zajímalo, co s tím vlastně uděláme
}
Pouze v případě, že je třeba v místě vzniku vyjímku lépe konkretizovat, aby bylo zřejmé, proč k chybě došlo. Tedy vygenerovat vyjímku novou, s lepším upřesněním problému.
Také jsem měl problém pochopit vyjímkový aparát .NETu a naučit se jej používat. Naštěstí je to jen otázka času (praxe) ;)
Datum vložení: 26.1.2005 6:51:48
hm, až na to, že zpracování výjímek v bloku try-catch spolkne pěknou režii navíc - jakkoli se budeš holedbat jak to máš čistě a přehledně, bude to nukleární hovado co zabere plno paměti...
Datum vložení: 26.1.2005 12:55:40
:o) hmm, i kdyby to byla pravda - co navrhujete? try - catch raději vůbec nepoužívat? :)
Datum vložení: 27.1.2005 9:43:23
Vyjimky se maji pouzivat u proceduralnich metod (void funkci), ktere interne pouzivaji vyjimky, lidove receno "tam, kde program muze spadnout a ja nejsem schopen to zjistit". Tim je napriklad prave spojeni na SQL server. Vas priklad s databazi je chybny, jelikoz ja jsem pred pozadavkem na clanek schopen zjistit, zda je, nebo neni, zda ID je integer, nebo jiny datovy typ. Pokud pouzijete vyjimku, vygeneruje se Vam nejaka obecna (coz je k nicemu), nebo budete muset tak, jako tak osetrovat typ vyjimky a to jste mohl udelat uz pred tim... usetril byste si tim reziji na vyjimku, navic se jedna o programovy skok, coz odporuje strukturovanemu programovani.
Vyjimky v pripade znalostnich chyb (deleni nulou, existence souboru, clanku) se maji generovat pouze ve vaznych pripadech na zaklade pozadavku na software (napr. knihovna pracuje se souborem a tento soubor je 'zivotnetne' dulezity pro funkcnost), nikoliv v pripade neexistence jednoho clanku, kdyz jsem jich pred tim vylistolav 300 a potom vylistutju dalsich 5000...
Datum vložení: 27.1.2005 16:32:07
Můj příklad chybný není. Kód sice vykáže obecnou chybu konverze, ale taky zobrazuji obecnou chybovou hlášku, takže je vše OK. Kdybych chtěl řešit každou mezní situaci explicitně, a vždy vypsat přesnou chybu, musel bych to samozřejmě řešit jinak, je to ale dost režijního programování navíc, a obvykle je to naprosto zbytečné (nemusím zdůvodňovat čtenáři, který zkusil sám pozměnit URL, proč se mu nezobrazil článek).
Celý váš příspěvek je důkazem, že stále nechápete podstatu problému: Chybu většinou nelze zpracovat v místě výskytu, ale na vyšší úrovni. Nenapsal jste, jak byste zpracoval výjimku ve funkci DejClanek. A to by mě zajímalo. Vrátil byste prázdný řetězec? Nebo null? Nebo dotyčnou chybovou zprávu? A co kdyby funkce měla vracet int, a nebo nic (void)? Právě tohle řeší výjimkový aparát, vy byste si vystačil s něčím, co si pamatuji ještě z ASP:
on error resume next
conn.Open
if err.number <> 0 then
... bla bla
end if
No nic, pište si aplikace jak chcete. Komu není rady, tomu není pomoci ;)
Datum vložení: 27.1.2005 12:54:20
Pane, co to plácáte? Dělení nulou není přece problém TYPOVÉ KONTROLY!!! A tady se, pokud vidím, řeší problém typové kontroly.
Netypovost jazyka PHP je jen historický důsledek toho, že vznikl pro jednoduché blbinky a pak už se u toho zůstalo; ale je to jednoznačně nevýhoda. Vy osobně, jako programátior, který asi není líný, opravdu u všech paramatrů, jak tady bylo zmíněno, kontrolujete typy explicitně? A jak to děláte u knihovních funkcí?
Datum vložení: 29.1.2005 1:26:00
Ač to není přímá reakce na mě, já s tím u knihoven problémy nemám. Vzhledem k tomu, že knihovna obvykle používá sama o sobě "svoje" funkce + konfiguraci, většina datových typů je jasná. V případě že se jedná o vstup uživatele, tam ošetřovat/testovat stejně musím tak jako tak - u řetězců délky, u čísel rozsah. Často není třeba ani kontrolovat datový typ, stačí přetypování - a pokud znáte konverzi typů mezi sebe, místo kontroly datového typu "stačí" proměnnou přetypovat. A těch vstupů od uživatele není obvykle závratné množství. Pro práci s databázi pak stačí využít objekt, který toto vše sám o sobě zaštiťuje (aneb vkládáte či upravujete sloupec xyz, tak se případná proměnná zkonvertuje do datového typu sloupce).
Datum vložení: 25.1.2005 15:37:46
No, zrovna tenhle příklad mi přijde jako příklad právě pro silnou typovost. To, co přiteče od uživatele, je evidentně řetězec, z databáze vybírám podle nějakého identifikátoru, kterým je zřejmě číslo. Tudíž, typový jazyk mě donutí tam dopsat nějakou logiku navíc, kde prostě <I>vidím</I>, že se tam může něco stát a musím ošetřit zvláštní případy. V netypovém jazyku se mi z toho řetězce stane nějak někde stane nějaké číslo, aniž bych si to musel uvědomit a ošetřit zvláštní případy. Netypový jazyk mě prostě nechá střelit se do nohy, což se někdy hodí, ale těžko popírat, že to je jedna z jeho vlastností.
Datum vložení: 25.1.2005 23:47:59
To že v striktně typovém jazyce něco provést musíte (zatímco v jazyce který striktně typový není nemusíte) neznamená že nemůžete. Přesněji řečeno, ve striktně typovém jazyce mi přijde v řetězci proměnná, a pokud lze tu proměnnou brát jako číslo, přiřadím ji konverzí do jiné proměnné s typem číslo. V jazyce, který umožňuje přetypování mi přijde proměnná kterou přetypuji na číslo.
Kde přesně vidíte tu "nevýhodu"? Pokud je někdo prase a neošetřuje, dělá bastly jako výše uvedené příklady (a příklady na testování SQL injection). Pokud někdo proměnné ošetřuje, má možnost i v PHP. Kde je tedy ta proklamovaná nevýhoda PHP? Já ji nevidím...
Datum vložení: 26.1.2005 14:46:33
Ve striktně typovém jazyce by neměla existovat implicitní konverze řetězce na číslo.
Kde je nevýhoda? Právě v tom, že musíte ošetřovat. Mám-li funkci, která pracuje s číslem, podle vás bych měl na začátku funkce ověřit datový typ. V typovém jazyce se tento typ u parametru vynutím, a pokud bych tam náhodou místo čísla někdy strčil řetězec, kód mi nejde spustit. Ve VS.NET s ReSharperem takovou nechtěnou situaci vidím dokonce už během psaní kódu. Ošetřování datových typů u vstupních parametrů je prostě naprosto zbytečná režie. V OOP, pokud využíváme dědičností, je plná kontrola typů také nezbytná. Složitější kód v netypovém jazyce může obsahovat velké množství zanesených a těžce odhalitelných chyb.
Datum vložení: 6.6.2006 13:55:28
Vy jste prostě zabedněnej blbec :-) Netypovost JE nevýhoda. Zatímco např. v javě odhalím spoustu chyb už při překladu* tak v PHP se objeví až při používání. Vaše argumentace, že "nemusíte ale můžete" je zcestná. Netypový jazyk vám ušetří jeden řádek kódu (nemusíte přetypovávat), ale uštědří vám nepříjemné hodiny debugování, v lepším případě. V tom horším se na chyby přijde až v ostrém provozu. PHP je nepochybně užitečný nástroj, ale musíte vědět, kdy ho použít a kdy je lepší vybrat jiný jazyk. *) což ovšem neznamená "jde to přeložit --> program je hotový" :-)
Datum vložení: 6.6.2006 14:00:26
"Vy jste prostě..." byla odpověď na Marabu :-)
Datum vložení: 26.1.2005 15:40:47
ja vyvijam obrovsku web aplikaciu v PHP 5 a musim sa priznat, ze na zaciatku metod vzdy otestujem datovy typ argumentov. Musim sa prizant, ze uz mi to ide na nervy !!! ale co mam robit?
Autor clanku zabudol na dolezitu vec ohladom magic_quotes_gpc.
magic_quotes_gpc je najvacsia hlupost !!! Ak vyvijate projekt v oop deaktivujte magic_quotes_gpc, verte mi vas zivot bude jednoduchsi.
<a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://www.phpe.net/manual/function.get-magic-quotes-gpc.php' target='_blank'>http://www.phpe.net/manual/function.get-magic-quotes-gpc.php</a>
To whoever invented the magic_quotes algorithm - I hate you ;)
This feature is a pain in the ass for all PHP developers. About every application has to check wether this is set or not and strip_slashes or not variables regarding its setting.
If this feature would not have been added a long time ago, everyone could've been told that you'd have to use addslashes to write secure SQL queries and stuff. But now you can not simply use addslashes, because magic_quotes might be in effect, so you have to stripslashes all variables at the beginning of your php file (if enabled) or even worse check and stripslashes each variable on usage.
This is a complex issue that truly doesn't make life easier for new and experienced coders and should have been removed with the suberglobals.
PS: Just being stuck again in forms that display \' \" sometimes and sometimes not - grah.
Datum vložení: 24.1.2005 23:20:13
Myslim, ze typovost ma vetsi vyznam nez jen jakasi jistota typu ocekavaneho parametru. V Jave muzu napriklad udelat nekolik metod stejneho jmena, ktere se ovsem lisi typem parametru. Podle toho pak mohu provadet ruzne operace. Je to ciste, rychle a efektivni. Z reseni, kdy bych mel nejprve zkoumat, jakeho typu je parametr, mi uprimne receno beha mraz po zadech ;o)
Datum vložení: 25.1.2005 10:49:24
Raději bych to napsal tak, že by jednotlivé varianty takto přetížené metody prováděly stejnou operaci, pouze nad různými datovými typy ;o) Jinak v C# je to taky tak. V PHP tohle nikdy nebude...
Datum vložení: 25.2.2009 18:38:47
vzhledem k tomu že to spotřebovává více paměti a je to o hodně pomalejší se musím připojit k tem kteří zastávají názor že php je pouze pro jednoduché aplikace.... rozhodně bych v tom nepsal nějaký složity šachový stroj
Datum vložení: 25.1.2005 8:03:40
V tomto případě budu stručný:
<a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://www.php.net/manual/en/language.oop5.typehinting.php' target='_blank'>http://www.php.net/manual/en/language.oop5.typehinting.php</a>
Datum vložení: 24.1.2005 5:51:59
<B>Podpora různých kódování řetězců</B>
....zapomnel jste na mb_ funkce
Datum vložení: 24.1.2005 9:51:12
Podla ide PHP jedinym spravnym smerom. Keby nepodporil objekty bolo by to preslapovanie na mieste. PHP 4 bolo urcene pre male a stredne projekty. Myslim ze tuto podmienku spolnilo PHP na 100%, tak kam ist dalej? Ostal jediny priestor enterprise level.. PHP 5 podla mna prinieslo objekty ktore boli potrebne ako sol na vystavanie skutocne kvalitnych frameworkov ako napriklad PRADO, alebo ine.. Co sa tyka netypovosti, tak tu povazujem za prednost PHP a podla mna prave jednoduchost PHP priviedla PHP tam kde je. To ze sa neda spravit skutocny polymorfizmus, je naskodu? Co je to "skutocny polymorfizmuz"? Mozeme tiez povedat ze PHP definuje poly morfizmus uplne inak. Co sa tyka objektov ktore vznikaju a zanikaju. Co tak si spravit script ktory bude bezat stale na pozadi? A objekty v nom uz budu vytvorene a komunikovat s normalnym scriptom cez message system (MantaRay)?
Datum vložení: 24.1.2005 10:14:34
Ahoj lefty, zajímavý článek :)
V několika věcech musím oponovat. Tak nejdříve k .NET. Ani u malých aplikací to není kanón na vrabce. V ASP.NET je totiž i psaní malých aplikací hodně snadné a rychlé. Stačí ve vizuálním módu VS.NET naházet na stránku nějaké DataGridy, Repeatery, Buttony a podobně, pak připsat pár řádků pro nabindování zdroje dat a je to. Není třeba vymýšlet vlastní objektový model, protože systém je na jednoduché aplikace sám o sobě připraven. A programátor nemusí ani nic moc vědět o dědičnosti nebo zapouzdření.
OOP v PHP bych neviděl tak zle, pokud někomu vadí, nemusí jej využívat. Taky mám v telefonu foťák, a nepoužívám jej ;) Ovšem občas se to může hodit. Vím o čem mluvím, taky jsem párkrát využil "class" ve VBS (ASP), i když tam si např. o dědičnosti můžu nechat jen zdát ;) No ale můj názor je takový, že se to tam implementovalo jen proto, aby byly umlčeny hlasy posměváčků, kteří z PHP dělali primitivní jazyk. Teď máme protiargument... Vidím to jako marketingový tah. Stejně jako když se do levných foťáků cpou čipy s velkým rozlišením, které tam jsou imho úplně zbytečné, protože ty foťáky stejně fotí hrozně...
Souhlasím s kritikou neřešených problémů s kódováním a vyjímkami, mělo by se to řešit. Ale asi by vznikaly problémy s kompatibilitou.
Datum vložení: 24.1.2005 10:55:32
no to stim VS.NET a rychlosti vyvoje aplikace je pekne, ale nemyslim si ze je to cesta spravnym smerem. Vymyslet si vlastni model by autor mel byt schopen sam. Lepsi reseni by bylo vymyslet vlastni model a ten nacpat do nejakeho webML a nechat vygenerovat kod.
Autor clanku ma pravdu, ze PHP neni na velke projekty. Ale prave rychlost vyvoje je to proc je PHP tak oblibene. Mimochodem kdysi jsem slysel jak vyvojari v JAVE bzikaji po nejakem skriptovacim jazyce, ktery by jim umoznil rychle neco napsat a ozkouset a pote to prepsat do javy. Takhle travi hodne casu psanim neceho co pak stejne nepouziji, ale museji se delat s typovou kontrolou atd. Mam ten pocit ze SUN dokonce uvazoval ze pouzije PHP jako skriptovaci jazyk pro JAVU.
Take mi to pripomina zoufalstvi kamarada, ktery se rozhodl ze teda PHP ne a ze JAVA. Psal malou aplikaci, kterou by mel v PHP hotovou behem tri dnu. V jave ji psal nekolik tydnu (pravda po vecerech), ale jeho stiznosti ze mu nejde upload souboru me bavily. Proste to co v PHP je otazka dvou tri radku kodu, je v JAVE otazka nejake tridy. Samozrejmne PHP mi neumoznuje takove veci jako JAVA, kde presne mohu zasahovat do prenosu. V PHP se to bud prenese nebo ne. To si musi kazdy uvazit sam, co chce s tim vyvadet.
A jeste jedna vec mluvi pro PHP. Porovnejete kolik hostingu nabizi JAVU a kolik PHP (ASP.NET neuvazuji). V cem budete psat aplikaci kdyz budete vedet ze u jednoho jazyka muzete kdykoliv prejit na jiny hosting a mate na vyber a u druheho jich mate jen par a cenove je to prast jak uhod?
Datum vložení: 24.1.2005 12:07:18
Je to flamewar, vy javu neznate a presto ji hodnotite podle porekadla "jednba baba povidala". Ze jsem tak smely, PHP trochu znam, uz existuje pro PHP nejaky MVC framework? Uz mam PHP komponentni pristup alias JSF (Java Server Faces) a Windows Forms (ASP.NET)? Existuje pro PHP nejake dostupne IDE? Myslim IDE a nikoliv editor kodu! Mohl bych pokracovat dale, prosim nehodnotte technologie, ktere neznate a drzte se tech, ktere mozna znate.
BTW s myslenkou integrace PHP si nepohraval Sun, ale byla predmetem JCP (Java Comunity Process) resp. JSR 223: Scripting for the JavaTM viz. Platform <a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://www.jcp.org/en/jsr/detail?id=223' target='_blank'>http://www.jcp.org/en/jsr/detail?id=223</a> a muj komentar <a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://www.sweb.cz/pichlik/archive/2004_03_14_archive.html#107950726983398000' target='_blank'>http://www.sweb.cz/pichlik/archive/2004_03_14_archive.html#107950726983398000</a>
Datum vložení: 24.1.2005 12:39:19
Trošku jsi mi nahrál na smeč. Pořadný framework v PHP chybí. A proč? Protože neexistovala pořádná podpora OOP. Očekávám, že verze 6 bude právě v tomto směru přelomová. Koneckonců, Zend (tvůrce PHP) tvorbu podobných aplikací podpořil vyhlášením soutěže a už nekolik (zajímavých leč nepoužitelných) pokusů se objevilo.
Framework nebude hned, ale dnes jsou podmínky pro to, aby vznikl.
Ad IDE: Nevím přesně, jaké požadavky na IDE kladeš. Mě osobně se velmi líbí Nusphere phpED (<a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://www.nusphere.com)' target='_blank'>http://www.nusphere.com)</a>, ve kterém se nezapře inspirace v Delphi. Tedy kombinace plnohodnotného editoru s integrovanou nápovědou a "Code Insight", debugger s podporou breakpoints, watch, atd... Existují i opensource řešení, jako třeba Eclipse.
Datum vložení: 24.1.2005 13:13:49
a co typo3? znate ho?
zajimal by me nazor co si o tom myslite
diky
Datum vložení: 25.1.2005 9:49:45
pouzivame typo3 uz viac ako rok, aj na vacsie projekty. da sa v tom robit a vyvijat, je to pomerne otvorena CMS platforma.
Datum vložení: 24.1.2005 14:31:58
add IDE.) Jedinym meritkem je pro me Eclipse, ktery pouzivam v Jave. Zaklad je debugger, code assistent, integrovana napoveda, refaktoring, integrovane cvs ... nevim asi by me napadaly jeste nejake dalsi veci, ale tezko rici co je zaklad a co nadstandard. O pluginu PHP do Eclipse vim, ale netusim jak moc to vyuziva vsech libustek, ktere nabizi rozhrani Eclipse.
Datum vložení: 24.1.2005 15:23:58
Já osobně jsem začal PHPeclipse nedávno používat a jsem nadšený. Sice použití debuggeru je trošku komplikovanější, alespoň co se týče jeho zprovoznění. I když já debugger zatim nevyužíval. Ovšem Code assistant a CVS používám. Jiná řešení (na NuSphere PhpEd se mrknu :)) nezenám, ale Eclipse je super. Takový je můj dojem. Sice má nějaká úskalí, resp. ten PHPeclipse plugin. Ale to nebude nic, co se nedá řešit. Jinak ostatních vlastností lze využívat stejně - TODO, Bookmarky, etc... a PHPeclipse má i slušnou kontrolu syntaxe, což taky neni na škodu.
Datum vložení: 27.1.2005 21:45:44
Tak to vam doporucujem Zend Studio - najlepsie IDE pre PHP ... ma takmer vsetko, len je na starsich strojoch pomalsi (ale staci vypnut kontrolu syntaxe).
Datum vložení: 3.2.2005 12:05:11
Rozhodně Komodo.
<a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://activestate.com/Products/Komodo/' target='_blank'>http://activestate.com/Products/Komodo/</a>
Vyzkoušel jsem phpEd, Zend studio a rychle se vrátil ke Komodu.
Datum vložení: 24.1.2005 13:12:40
MVC Framework? Mojavi.org a kopec ďalších čo boli už na PHP4.
Komponenty? Napríklad PRADO framework
Datum vložení: 24.1.2005 14:37:46
add mojavi .) vypada dobre a navic vychazi ze Struts. Na druhou stranu jak hodne to nuti vyvojare pouzivat MVC? V jave je pouziti MVC (Struts) takrka standardem.
Datum vložení: 25.1.2005 8:15:45
"jak hodně to vývojáře nutí...?"
Promiňte, ale jsem relativně svobodný člověk. Chci dělat svobodná rozhodnutí, chci se z nich poučit. Chci chápat, proč dělám to, co dělám. Tím, že mě něco k něčemu nutí, mi to jednak vadí (prostě to nemám rád), jednak mě to zdržuje, protože si to nemůžu udělat svým způsobem.
Preferuju programovací jazyky, které mi umožňují řešení problému, nikoli takové, které mi jej vnucují.
Datum vložení: 25.1.2005 9:02:01
Ne ne, vubec jste me nepochopil. Bylo mysleno tak, ze obecne nuti k MVC pristupu, ktery je jediny spravny. Navic MVC nema s jazykem jako takovym co delat. MVC je jen obycejny navrhovy vzor,
Datum vložení: 25.1.2005 9:29:12
Přesto myslím, že jsem Vás pochopil. Někdo / něco mě nutí k MVC přístupu, o kterém někdo usoudil, že "je jediný správný".
Představte si, že to čte geniální 14letý člověk (třeba můj oblíbený Pepík). Pokud bude dotlačen k nějakému funkčnímu řešení (např. MVC), může se stát, že u něj zůstane a zaměří svou genialitu jiným směrem. Pokud dotlačen nebude, může se stát, že v 16 letech vyvine něco jiného, objektivně lepšího. Protože nebude svázán minulými myšlenkami a bariérami. Třeba to vyvine i tak, nebo to vyvine později. Kdo ví.
Proto tvrdím, že toto "tlačení k jedinému správnému postupu" je kontraproduktivní. Vadí mi tam ta atmosféra nebo... náznak, že je to jasné, definitivní, objektivní, univerzálně platné. Možné to je, ale já tu jistotu nemám a jsem tomu rád. Ano, mohu být přesvědčen autoritou v oboru, ale to ještě pořád naznamená, že je to pravda. (to už jsem se dostal hodně daleko od článku)
Myslím si tedy, že by nikdo neměl být nucen k nějakému konkrétnímu postupu už jen vzhledem k jeho potenciální genialitě, potenciálnímu pokroku, chcete-li. Preferuji metodu nabídky (a platí to obecně, ne jen v programování).
Datum vložení: 24.1.2005 17:48:28
A koukam byl jsem nepochopen. Ja nechci rozpoutat flamewar. Chtel jsem jen poukazat na to ze nektere veci se proste v PHPku resi lehceji. Nechci rovnat JAVU a PHP do jedne roviny. Spis jsem mel na mysli pouzitelnost u mensich webu.
A JAVU trochu znam. V ramci semestralni prace ve skole jsem napsal sitove sachy pro dva hrace. Priznavam neni to zadna poradna praxe, ale na to abych o jazyku neco malo vedel to staci.
Datum vložení: 25.1.2005 7:14:13
Ja jsem zase v ramci diplomky (2001) psal intranetovou aplikaci v PHP, takze jakou takous predstavu o PHP mam. Samozrejme, ze nektere veci v PHP resi lehceji, protoze se jedna o "obycejny" skriptovaci jazyk, kde byl easy of use takrka na prvnim miste. Java je cela platforma, proto bych se zdrahal nejakeho srovnani skriptovaciho jazyku a plaformy. Pokud tvorite webovou aplikace v prostredi Javy, tak pouzijete s nejvetsi pravdepodobnosti JSP a pripadne budete vyuzivat servlety. Bylo by na miste tedy srovnavat JSP+Servlet vs. PHP.
Datum vložení: 25.1.2005 4:50:31
> uz existuje pro PHP nejaky MVC framework? Uz mam PHP komponentni pristup alias JSF (Java Server Faces) a Windows Forms (ASP.NET)?
<a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://www.whoa-framework.org' target='_blank'>http://www.whoa-framework.org</a> :) byt nejsou informace na strance ani z 5% uplne..
Datum vložení: 24.1.2005 12:54:56
> Vymyslet si vlastni model by autor mel byt schopen sam.
Prosímvás vymýšlet model tam, kde je již jednou u základních věcí model vymyšlený je dnes překonaná věc - nasekáte tam spoustu chyb, a to co někdo už jinde vymyslel za vás vy budete vymýšlet odznovu?
Osobně bych vám doporučil se seznámit s tzv. "Návrhovými vzory", které zachycují určitý jednotný netriviální scénář - řada známých návrhových vzorů je implementována jak v Javě, tak v .NET, i když v .NET to není tak patrné, zřejmě se MS snaží ve vizuálním prostředí programátora od toho oprostit. Znovu ale opakuji, že vymýšlet znovu a znovu model chování aplikace je překonané - určitě byste nechtěl v PHP vymýšlet vlastní mechanismus sessions, když tam tento je implementovaný a funkční.
Právě chybějící povědomí o návrhových vzorech vede programátory oněch podivných opakovaně nepoužitelných skriptů k názorům, že nejlepší je to, co si napíšu sám - naštěstí to není pravda :)
Datum vložení: 24.1.2005 12:57:51
<I>...určitě byste nechtěl v PHP vymýšlet vlastní mechanismus sessions, když tam tento je implementovaný a funkční...</I>
Ještě rok či dva zpátky bylo právě tohle příznakem "správného" programátora PHP ;-)
Datum vložení: 24.1.2005 15:27:32
Tak tak, já sám se v tom také vidí. Řadu věcí jsem si radši napsal sám, protože řešení cízí mi prostě nevyhovovala. Není to tak dlouho, co se snažím používat interfejsy (dobrým zdrojem může být phppatterns.com).
Datum vložení: 25.1.2005 8:27:33
Následující text není myšlen jako urážka nebo útok na Vás.
Kdo jste, že mi (jako příkladu jedince z obecenstva) říkáte, co je a co není správné? Bůh? Valheru? Předpokládám, že ani jedno.
Ano, existují design patterns a ano, mohu si napsat něco jiného sám. Kde berete jistotu, že já (jako příklad náhodného jedince z obecenstva) nejsem ve schopnosti abstrakce, algoritmizace, ... mnohem dál?
Podle mého názoru je správné říct mi: "Podívej, Pepíku, existuje XY a má to tyto výhody a nevýhody. Pak existuje XZ a má to tyto výhody a nevýhody." A já se rozhodnu, zda jsou ty výhody a nevýhody pro mě podstatné. Ale říct "XZ je dávno překonané" (zvlášť v případě, že vlastně ani nevíte, o čem konkrétně mluvíte, protože jste to prostě nemohl nikde vidět), mi přijde poněkud odvážné. (Znovu opakuji, je to jen můj názor, se kterým pochopitelně nemusíte souhlasit. Ale stojím si za ním.)
Datum vložení: 24.1.2005 12:34:14
ale na druhou stranu pro člověka, který píše téměř jenom malé a střední webaplikace je PHP lepší z důvodu toho, že si na komp nainstalí apache a php, mysql a může pracovat a vše může ladit doma offline, pro MS řešeni musí instalovat drahý software jako je MS server 2003, nebo nějaký starší MS server
Datum vložení: 24.1.2005 12:57:10
nemáte pravdu, nic tak komplikovaného instalovat nemusíte - stačí si stáhnout zdarma nástroj WebMatrix i s vestavěným webserverem Cassini (pokud nechcete použít IIS, který je zdarma součástí W2K a WXP Professiona) a můžete vyvíjet
Datum vložení: 24.1.2005 13:24:18
ani to nemusi byt okna - viz mono project
Datum vložení: 26.1.2005 11:35:39
V tom případě se ovšem připravte na občasné veselé šoky. Což říkám z pozice člověka, kterému osobní pidiwebík už rok a půl na Monu jede a který je rozhodnut od něj zdrhnout, jakmile mu zbude trocha času na přepsání všeho do Javy.
Datum vložení: 24.1.2005 10:23:40
To se Vám skutečně zdá tak důležité? Mně osobně je jedno jestli je správně inarray, in_array, InArray, INARRAY, nebo co. To přece není žádná závažná vada.
Datum vložení: 24.1.2005 11:01:47
Ano, je to skutečně důležité. Při rozumném (ať jakémkoliv konkrétním) systému pojmenování člověk dokáže většinou uhádnout jméno i u míň používaných funkcí místo, aby musel hledat v manuálu. A co je nejspíš ještě důležitější je, že systém v pojmenování u systémových funkcí dává návod autorům knihoven, takže jejich používání je pak významně jednodušší.
Datum vložení: 2.2.2005 23:10:06
Please, tell me too
vladimir.solc@cnzp.cz
Datum vložení: 3.2.2005 2:22:37
Viz naříklad <a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://pear.php.net/manual/en/standards.naming.php' target='_blank'>http://pear.php.net/manual/en/standards.naming.php</a> ;-)
Datum vložení: 24.1.2005 10:58:07
Když jsem začínal s PHP, tak mi dost vadila chatrná podpora modulů. Jistě, můžete nějaký soubor includnout, ale pak riskujete kolizi s názvy interních funkcí a proměnných. Mnoho lidí tak používá objekty jako náhražku, aniž by využili skutečných výhod OOP. Schválně si vzpomeňte v kolika vašich projektech využíváte třeba jen dědičnost, nebo kolik objektů existuje ve více než jedné instanci.
To mi připadá jako hlavní problém PHP. Třeba programování v C# je díky OOP velmi rychlé a přehledné, ale v PHP mi nepřipadá zdaleka tak elegantní. Myslím si, že hodně programátorů tam má "nějaké ty objekty, aby to měli objektově" a nebo tím řeší jen neexistenci podpory modulů.
Datum vložení: 24.1.2005 12:31:20
To je naprostá pravda. Objekty jako náhrada modulů nebo jmenných prostorů, to je klasika. Spousta programátorů pak nazývá své spagetty-OOP programy objektovými a vydává jejich objektovost za přednost. Jenže... ona to skutečně přednost je.
Zkrátka, už kvůli neexistenci modulů, vždy raději sáhnu v PHP po objektovém řešení. A tím pádem je podpora objektů v tuto chvíli klíčová.
Datum vložení: 24.1.2005 13:27:19
Toto je výborný postřeh, řada objektů v aplikacích skutečně vzniká jen z tohoto důvodu. Nicméně, třeba nově zavedená možnost uživatelských konstruktorů/deskruktorů je výborná věc, a výjímky, člověk už pak nemusí volat řadu věcí explicitně a dá se vytvořit snadněji udržovatelná aplikace, včetně dědičnosti (mám třeba základní třídu Plugin, a na ní navazující implementace jednotlivých pluginů, plus třídu Manager, která se stará o událostmi řízený model, a toto je skutečné využití objektů i v PHP).
Datum vložení: 24.1.2005 11:25:26
Mam pravou ruku v gypsu, takze jen bodove:
- jmena fci - je jedno zda MySQLexec nebo mysqlexec - je tocase ins. - horsi je to s MySQL_Exec vs. MySQLExec (vymysl. priklad)
- typovost - prave jsem napsal v PHP parser cistye binarniho filu - to, co bych psal v Cecku pul dne s hromadou mallocu, to bylo v PHP i s odladenim 1h... kdyz clovek chce typovost, tak ji muze mit, ale vetsinou je to spis na obtiz
- objekty - mam projekt v PHP s 50 ksloc a docela uvazuju nad objekty JEN kvuli namespace. pravda, ze "persistent" objekty by byly na par veci super
Datum vložení: 24.1.2005 14:39:00
Myslím, že autor článku je úplně vedle. PHP zprvu vypadá jako hračka pro děti, ale při dobrém použití může překonat i Javu.
Při velkých projektech se jako největší zádrhel ukazuje špatný přístup programátorů. Nepoužívání šablon je katastrofální problém, který vyústí v nespravovatelný projekt. Naopak, použití například Smarty umožňuje v PHP tvořit velké projekty, které se dlouhodobě velmi snadno spravují. Smarty je typický příklad šablon, na které první dva týdny nadáváte, že to jde pomalu a další rok pochvalujete, že to jde nádherně upravit.
Java má své nevýhody. Musí se všechno zkompilovat, zcela banální věci se řeší neuvěřitelně komplikovaně atd. Java má ovšem dvě základní výhody.
1) Nutí programovat objektově, čistě a ve stádiích, jinak to tam nejde. U PHP je většinou selhání na straně projektových manažerů, kteří mají velmi špatnou specifikaci projektu a pak z komára dělají velblouda. Stává se, že u klientů z jednoho formuláře vznikne IS a tak to dopadá.
2) Java je snadno napojitelná na aplikace v Javě, které běží na PC, Mac, Linux. Integrace je prostě silná a solidní.
Nicméně i tak můžu říci, že při dodržování dobrých pravidel je PHP rychlé a efektivní i na větší projekty. Při použití Smarty lze navíc efektivně předejít většině problémů.
Problém PHP je jasný, programují v něm nejvíce amatéři a ty kazí pověst. Lidí co opravdu umí v PHP dělat je jako šafránu, proto se nedivím, že hodně lidí preferuje Javu či .NET.
Mimochodem .NET bych na větší projekt nikdy nepoužil. Podle mě neexistuje snad horší vývojové prostředí, které umožňuje tolik prasáren.
Datum vložení: 24.1.2005 15:37:56
Tak jedna věc je naučit se vůbec v něčem programovat a pak se stát zkušeným programátorem. Každý musí někde začít. Ale na druhou stranu znám pár lidí, kteří se jaksi pokouší "programovat" v PHP a opravdu na to nemaj. PHP má tuto nevýhodu, že umožňuje psát bastl. Bohužel. Největším znakem tohoto chování je možnost nepoužívat funkce/procedury. Ovšem je to právě široké spektrum lidí, kteří PHP používají a kteří zajišťují jeho popularitu.
Šablony? Určitě. Zrovna autor webu phppatterns.com je silně proti nim. Tedy alespoň proti těm "programovaným". Já osobně Smarty v oblibě nemám, protože je příliš robustní. Je to prostě framework na tvorbu frontendu. A pro moje drobné potřeby jsem moc líný se učit s ním pracovat. Proto mám svůj vlastní šablonový systém. Sice by potřeboval jisté přepracování, ale koncepce je jasná - má určité fičurky, co má Smarty, ale je celkem snadný na použití. Tady se taky projevuje ona tendence "napíšu si vše sám". Bohužel.
Datum vložení: 24.1.2005 15:40:36
Ad můj šablonový systém - zapomněl jsem říct, že je oproti Smarty malý a rychlý.
Datum vložení: 24.1.2005 21:07:38
Propooh! Smarty a slozity? Ja sem se to naucil za cca tri hodiny a myho tureckyho kolegu (jinak absolutni drevo) sem to ucil cca den.
Tim samozrejmne nechci rict nic proti Vasi knihovne, nicmene radsi vrazim par hodin do uceni neceho slusnyho, nez bych si par dni, tejdnu smolil neco dokonalyho :-).
Datum vložení: 24.1.2005 23:42:22
Hláška, že .NET je vývojové prostředí svědčí o tom, že vůbec nevíte, co to je. Vývojové prostředí je třeba Visual Studio.NET. Samotný .NET je Framework (knihovna tříd atd.)
A proc byste .NET nepoužil na velký projekt? Je to jenom díky špatnému "vyvojovemu pristředí"? BTW. Zkuste např. C# builder od Borlandu...
Datum vložení: 25.1.2005 13:06:45
Není to tak jednoduché. Vývojové prostředí lze chápat jako terminus technicus pro IDE. Na druhou stranu, když mluvíme o tom, že programujeme v nějakém jazyku s určitými knihovnami pro určitý interpret apod., tak nevidím nic tak špatného na tom že člověk řekně, že to programuje "v prostředí Javy" (právě proto, aby člověk nemusel použít to Vaše ".atd"). A použít v této souvislosti přídavné jméno "vývojovém" (v tom prostředí kromě spuštění konečného produktu probíhá i vývoj) mi zase tak podivné nepřijde.
Datum vložení: 25.1.2005 15:32:48
hmm. Zajimave.
<I>PHP zprvu vypadá jako hračka pro děti, ale při dobrém použití může překonat i Javu.</I> ..Tak tohle je moc i na me.
Vase uvedene 2 zakladni vyhody Javy jsou take velmi zajimave.
ad1) OOP neni od toho, aby programatora do neceho nutil. Pletete si podminku a dusledek.
ad2) pokus myslite JVM, souhlasim, ale to nejsou zakl. vyhody.
<I>Problém PHP je jasný, programují v něm nejvíce amatéři a ty kazí pověst. Lidí co opravdu umí v PHP dělat je jako šafránu, proto se nedivím, že hodně lidí preferuje Javu či .NET.</I>
Z toho vyplyva, ze radsi pouziju .NET nebo Javu, protoze je malo lidi co umi dobre PHP. ...Tak takove pohlizeni na vec me opravdu desi.
Pokus muzu poradit, nesrovnavejte. Napiste, co se Vam na PHP libi co ne, ale nesrovnavejte. Java neni skriptovaci jazyk, je to platforma a to je hoodne velky rozdil. Je primarne urcena na to, aby se na ni stavelo. Viz. mnozstvi technologii, ktere z ni vychazeji. Jejich pouziti je potom na diskuzi.
.NET prilis neznam, ale to, ze umoznuje prasarny, neni argument. To by se proti PHP dalo pouzit mnohem snadneji. viz $$ :)))
Datum vložení: 26.1.2005 22:16:17
.NET je naopak vysoce profesionalni a typove prostredi. Napsat bastl neni NIKDY vinou nejakeho vyvojoveho prostredi, ale je to typicka hlaska nekoho, kdo proste neumi programovat. Tuhle zminku jsem slysel jiz mockrat od programatoru v libovolnem prostredi a platformne, obvykle je to jinymi slovy to, ze oni tomu nerozumi, a proto to prostredi je spatne, protoze oni v nem pisi bastly.
Jinak .NET neni VS.NET, to je naprosty omyl. Krome toho .NET jiz dnes bezi v pohode na Linuxu, BSD, Mac OS a to jak v podobe Mona, tak dalsich runtimu. Mimochodem kdyz se nyni podivate na Javu, tak ta jen kopiruje to, co .NET a C# prinesl - typicke jsou atributa a metadata, nebo autoboxing. Asi pred 4 lety (.NET byl uveden v roce 2000) Sun tohle silne kritizoval a dnes to je v 1.5, dalsi prejate veci jsou JSF, ktere odrazeji server controls a podobne je ted upravovane verze J2EE1.5, hlavne problemy s home-remote rozhranimi. To je nesvar, co je prejaty diky spatnemu navrhu a trochu kopirujici DCOM Microsoftu, ale pritom spatny. Kdyz vezmete Enterprise services nebo remoting, tak ty jsou mnohem snazsi a transparentni a pritom maji enterprise vykon (viz. napr. nyni oceneni od Waters magazinu pro .NET a hodnocenu NASDAQem jako nejlepsi platformy pro vyvoj enterprise systemu). Trochu se naucte o jednotlivych platformach a pak nebudete psat tyhle skutecne nepravdive veci.
Jinak muj nazor je to, ze Java a .NET jsou VELMI spickove platformy (PHP urcite ne) a pouze je nutne se naucite je vzajemne pouzivat pak vyuzit jejich slabiny a silne stranky ke spokojenosti klientu.
Datum vložení: 3.2.2005 14:23:00
re: Mimochodem kdyz se nyni podivate na Javu, tak ta jen kopiruje to, co .NET a C# prinesl -> mozna mate pravdu, ale pred lety to byl prave C# ktery vykradal javu. Mj java podporuje urcite struktury, ktere treba c# nema (anonymni tridy).
Proti c# toho moc nemam akorat me vadi jeho "multiplatformnost" ktera jaksi chybi. Nahrazky typu Mono bohuzel nenahradi ten pravy runtime (mono je kvalitni ale prikladem budiz "vymyslenost" kompilace .dll kvuli chybejici API dokumentaci)
Datum vložení: 24.1.2005 18:37:07
Autor trosku pozabudol na moznost objekt + session, a ziadna struktura objektu sa nemusi vytvarat odznova ... A ak k tomu pridam naozaj svizny templatovaci system (Pear::Html_IT) + nejaky jednoduchy system komponentov (nazvime ho neskromne framework), da sa s PHP siahat aj na maty velkych projektov. Sam na takom pracujem bez toho aby som mal v hlave ze PHP na to nestaci, jasne moznosti java like jazykov (ja C#) by sa niekedy zisla, ale budete chciet znovu a znovu kompilovat kod ???
Ja osobne si myslim ze PHP sa vyvija dobrym smerom, a ak sa z PHP6 stratia vsetky neobjektove funkcie, budem velmi rad. Je jasne ze na to treba zaviest konvencie pomenovani, ale to je vec contributorov PHP (alebo Zend-u, ak to chce menezovat)
Inak suhlasim ze niekedy sa clovek pozastavi nad vecou ktore nie je doriesena, ale je to open architektura, takze nech sa paci kazdy moze prispiet svojou troskou...
PS: exception handling : co vam brani aby ste v PHP5 napisali vlastny exeption handler, len extendnut Exception a idem
Datum vložení: 24.1.2005 18:55:08
Nemůžu si pomoct, ale autor článku budí dojem, že prostě protože on neumí používat PHP v komplexnějším smyslu a na větších projektech, tak to prostě nejde. Mimochodem, větší projekty stejně obvykle přesouvají logiku aplikace někam úplně jinam (např. do databáze).. Jistě, PHP má řadu chyb i ve své páté verzi, ale že se vydává správným směrem, o tom není pochyb. Možná by si autor mohl zkusit najít ve vyhledávačí nějaký open source CMS systém nebo framework a zjistil by, jak se dá PHP používat efektivně a že se vyvíjí opravdu tím správným směrem.
Datum vložení: 24.1.2005 19:03:17
Přesun "obchodní logiky" do databáze je nejen nešvar líných programátorů, ale také hrubé zneužívání databází, které se vám časem vymstí ;-)
Datum vložení: 24.1.2005 19:38:17
To bych neřekl, spíš se to dělá asi kvůli výkonu. Faktem je, že je to obvykle hůře čitelné, špatně se to ladí, a řada věcí se tak dělá hůře, nebo nejde udělat vůbec.
Datum vložení: 24.1.2005 19:46:57
Ano, hlavní pohnutkou pro vznik tohoto "posunu" byl výkon, v dobách, kdy "železo" bylo drahé a výkonem se nesmělo plýtvat. Tehdy pár líných programátorů přišlo na to, že sice sami napsat kvalitně odladěnou aplikaci neumí, ale databázový server je v tomto směru odladěn špičkově - takže přesunuli co nejvíce práce na něj. A od té doby tady máme tuhle skupinu zvrhlíků, kteří namastí extra super aplikaci za dva dny, ale když ji má po nich převzít někdo jiný nebo když ji mají po měsíci upravit, tak je nutno celou věc napsat znovu a ještě vyměnit databázi! ;-((
Datum vložení: 24.1.2005 22:58:09
Toj je nesmysl, přesun obchodní logiky do databáze, jako uložené procedury a triggers, v PL/SQL, je ta jedená možnost jak dělat skutečně rozsáhlé aplikace.
Jeden ze systémů, na kterém dělám, má 90% funkčnosti psaný pod Oracle databází, něco málo, 8% je ve Forte C++ na Solarisu, jako aplikační servery, a k tomu se připojují různým způsobem klienti, formou Win aplikace, pomocí SMS, pomocí HTML front-endu, a to i více způsoby v reálném čase. Jediná možnost, jak toto naprogramovat bezpečně, stabilně a pro extrémní výkon je použít databázi.
A databází zde nemyslím MySQL či PostgreSQL.. ;)
Datum vložení: 24.1.2005 23:03:35
To je ale špatný postup, zděděný z dob fanatického prosazování dvouvrstevných struktur typu klient/server. Zde je na místě použití třívrstevné struktury, kde základem bude databáze (lhostejno jaká, klidně něco lehkého a free), nad níž operuje aplikační server a teprve k němu se budou připojovat různé aplikace a klienti ;-)
Datum vložení: 24.1.2005 23:45:48
A o čem píšu? O relaci frontend -- aplikační server ve Forte C++ -- databáze ;-) Lépe číst, doporučuji ;)
Samotná aplikační logika je ale pochopitelně v databázi, třeba validace objednávek, potřebuje ji více aplikačních serverů a je zcela nesmyslné tyto data tahat z DB do Aplikačního serveru a tam zpracovávat, takto se v reálném čase nedá pracovat.
Datum vložení: 24.1.2005 23:48:49
PS: three-tier architecture používáme firemně asi 8 let, na three-tier architecture běží třeba naše obchodní systémy v Komerční bance, České spořitelně, či PPF burzovní ;)
A veškerá logika je na DB, cpát ji do aplikačního serveru je hloupost. Ono to ani jinak nejde, pro real-time aplikace, jako je napojení na MAOS (online obchodní systém Pražské burzy cenných papírů)
Datum vložení: 25.1.2005 0:14:35
Uznávám, že nemám zkušenosti s burzovními aplikacemi, ale zase jsem pracoval na armádních systémech, takže mám dojem, že o tom něco vím ;-)
Jednoduše si myslím, že splývání databází s aplikačními servery je chybný krok. Možná funkční, ale systémově nesprávný ;-)
Tuhle otázku asi vyřeší až čas - ale to už jsme silně OT, takže prosím konec této diskuse ;-)
Datum vložení: 25.1.2005 1:36:56
Jen dodatek, silně OT, mě se zase v praxi pro systémy, co jimi protékají stovky miliard Kč ročně, osvědčilo veškerou logiku přenést na Oracle databázi, psanou jako triggery (události) a uložené procedury, které jsou volány aplikačním serverem (na který se napojují klienti). Vyzkoušeli jsem různá řešení a toto bylo jednoznačně nejstabilnější a nejrychlejší (třeba v KB jede Oracle na SunFire serverech za takovou desítku mil USD)
Datum vložení: 25.1.2005 11:06:21
Když je programátor zvyklý psát aplikace určitým způsobem, a aplikace je už hotová, těžko se posuzuje, zda by nebyl jiný způsob efektivnější.
Datum vložení: 25.1.2005 15:45:16
Právě se bavím tím, jakou jsem rozdmychal diskuzi. Souhlasím s Vámi, jak už je patrné z mého stanoviska výše. Prostě se musíme smířit s tím, že Interval nečtou jen profesionálové z oblasti enterprise :-) nebo nadšenci, kteří znají enterprise-level.
Pánové zde by zřejmě zrušili půlku výrobce databází jmenovaného výše a zaměstnancům by řekli, že jejich práce je k ničemu, bezvýznamná a nikdo jí nepoužívá :-)
Datum vložení: 27.1.2005 22:46:32
hmmm, a preco "výrobce databází jmenovaného výše" vyvija aplikacny server, ked aplikacna logika v databaze je to spravne? ;)
Datum vložení: 11.2.2005 1:56:43
přenesení aplikační logiky do pl/sql je krásná věc, vše hezky pohromadě. Parsujeme stovky xml souborů s košatou strukturou. PL/SQL procedura v Oracle mí cca 4000 řádků coož odpovádá 200k kódu. Už sama o sobě je ta package obrovská na to aby se v ní člověk vyznal... Největší problém mi ale dělá XMLDOM parser který je v oracle řešený v JAVA (používáme v9 nevím zda v desítkových verzích nedošlo k využití "céčkového" parseru) a jen samotné načtení xml do dom objektu a jeho validace je docela dlouhá, pravda pak je ještě hodně validační logiky kolem každý záznam se kontroluje vůči existujícím datům (hledají se duplicity) a jelikož nejde použít jedinečného ID zasílaného záznamu (neexistuje u odesílatele, odesílatel = 17 firem, různé verze sw jeden jasně definovaný XML který však nevyžaduje jedinečné ID), takže duplicitu člověk hledá vůči cca 4-7 položkám což už jsou docela slušné dotazy, zvláště když při tom louská statisíce záznamů... Zpracování cca 2MB XML souboru pak trvá i 4-5 minut a představím-li si že nám může podobné zvěrstvo poslat cca 5000 subjektů najednou... i když budeme maximalizovat hw v únosné cenové míře budeme muset pro parsování xml zvolit jiný způsob než PL/SQL
Datum vložení: 3.2.2005 12:14:15
s větou:
A databází zde nemyslím MySQL či PostgreSQL.. ;)
musím nesouhlasit. Svědčí o tom, že už jste se dlouho nerozhlídl kolem sebe. Postgres je na tom hodně dobře a setkávám se s nim u opravdu náročných projektů. Oracle znamená značku, nikoliv však už kvalitu, se kterou se nejde srovnat.
Datum vložení: 11.2.2005 2:12:55
no sice musím souhlasit že oracle je velká značka, stejně jako třeba sybase... cenová politika je u obou skoro stejná... co se týká free databází nezavrhuji je, je jasné že mají svá pro a proti. dělal jsem dlouho na mysql a stále ji ještě využívám, ovšem budete-li dávat dohromady systémy ze v diskuzi zmíněných enterprise řešení, což jsou třeba bankovní, burzovní ale také třeba zdravotnické aplikace, pak nemůžete použít nic free, zvláště pak open source. pro všechny by to byla záhuba, protože každý by mohl vidět kód dtb serveru a případně v něm najít slabinu či bug kterého by mohl využít... když odrovnáte bankovní server bude to pro klienty zlé ale nějak to ustojí, ovšem když banka řekne náš systém stojí na Postgres tak věřím že většina informovaných služby této banky nevyužije. Problém kritický v případě selhání vidím v nemocnicích. Když klekne databáze bude to velký problém a mohou umírat lidé. Už vidím jak pak správci systému volají do zahraničí nějakým "fandům" jak oživit data... Tím že kupujete enterprise řešení neznamená že kupujete kvalitu - to ne, kupujete kvalitu(kvalita neznamená jen rychlost ale také funkčnost) a bezpečnost o kterou jde především... také kupujete možnosti... nevim zda třeba postgres jde vrazit do clusteru kde výpadek jednoho stroje neznamená konec pro aplikaci... nevím zda můžete PL/SQL řešit generování a odesílání direct emailů, pravděpodobně se o postgres nemluví jako o xml nativní databázi (v oracle lze XML které má registrované XML schéma uložit jedním insertem a nejen insertem ale třeba jen zkopírováním na "FTP" či určitou "síťovou složku") atd. atd.
Datum vložení: 11.2.2005 2:13:07
no sice musím souhlasit že oracle je velká značka, stejně jako třeba sybase... cenová politika je u obou skoro stejná... co se týká free databází nezavrhuji je, je jasné že mají svá pro a proti. dělal jsem dlouho na mysql a stále ji ještě využívám, ovšem budete-li dávat dohromady systémy ze v diskuzi zmíněných enterprise řešení, což jsou třeba bankovní, burzovní ale také třeba zdravotnické aplikace, pak nemůžete použít nic free, zvláště pak open source. pro všechny by to byla záhuba, protože každý by mohl vidět kód dtb serveru a případně v něm najít slabinu či bug kterého by mohl využít... když odrovnáte bankovní server bude to pro klienty zlé ale nějak to ustojí, ovšem když banka řekne náš systém stojí na Postgres tak věřím že většina informovaných služby této banky nevyužije. Problém kritický v případě selhání vidím v nemocnicích. Když klekne databáze bude to velký problém a mohou umírat lidé. Už vidím jak pak správci systému volají do zahraničí nějakým "fandům" jak oživit data... Tím že kupujete enterprise řešení neznamená že kupujete kvalitu - to ne, kupujete kvalitu(kvalita neznamená jen rychlost ale také funkčnost) a bezpečnost o kterou jde především... také kupujete možnosti... nevim zda třeba postgres jde vrazit do clusteru kde výpadek jednoho stroje neznamená konec pro aplikaci... nevím zda můžete PL/SQL řešit generování a odesílání direct emailů, pravděpodobně se o postgres nemluví jako o xml nativní databázi (v oracle lze XML které má registrované XML schéma uložit jedním insertem a nejen insertem ale třeba jen zkopírováním na "FTP" či určitou "síťovou složku") atd. atd.
Datum vložení: 24.1.2005 22:33:13
Nevím co jsi psal za aplikace, ale předpokládám že jsi skončil někde na úrovni databáze -> php a zpět s "obchodní" logikou "vlož do tabulky co přijde z formu". Přemýšlel jsi někdy nad problémy způsobenými duplikací kódu v architektuře, kdy na jednu databázi se připojuje více různých typů aplikací (např. PHP a CMS psaný v C++)? Zkus to odladit.
Na druhou stranu souhlasím s autorem, protože při tvorbě 2 denního webu u kterého se neočekává rozšíření logiky jsou storové věci zbytečný luxus.
Datum vložení: 24.1.2005 23:01:28
Nemusíte se bát, nezůstal jsem na úrovni, o které zde mluvíte. A k mému názoru mne nevede jen má vlastní zkušenost, ale také utrpení tisíců praktických programátorů i analýzy teoretiků žánru. Pokud jste si nevšiml, většina programátorů je <I>proti</I> přesunům aplikační logiky do databází.
Mimochodem, právě to, co zde dáváte za příklad (tedy databáze spolupracující s více aplikacemi), je typickým případem, kdy přesun aplikační logiky do databáze je naprosto nesmyslný. Takové situace se totiž řeší použitím třívrstvové struktury, kde nad databází operuje aplikační server a teprve k němu se připojují jednotliví klienti/aplikace ;-)
Datum vložení: 25.1.2005 12:21:10
A není logika v databázi náhodou typický příklad 3 vrstvé architektury, kde je datová vrstva a její logika umístěna sice v jednom serveru, ale v oddělených vrstvách?
Datum vložení: 25.1.2005 16:24:11
Neni to tak, u spravne 3 vrstve architektury muzeme klidne vymenit
DB za jinou (treeba zakaznik nechce Oracle, kdyz mu vsee bezi na MSSQL) a nic se nemusi predelavat (krome DB install scriptu)
To co popisuje bych nazval neco jako 2.5 vrstvy model - neni to tak, ze aplikacni server obsahuje primo nejake SQL prikazy, ale jen volani Stored procedur. Ostatni se deje v tech procedurach dane DB. Tento model ma sve vyhody, tak i nevyhody, stejne jako 2 a 3 vrstvy model.
Datum vložení: 27.1.2005 8:33:34
Co se časem vymstí je bohužel přesný opak, přesouvání databázové logiky do PHP. To co jsem viděl - LEFT JOIN řešený v PHP přes spojování polí, patří k odstrašujícím příkladům.
Logika v databázi je bezvadná věc. Výkonově se to ani nedá srovnat. Když člověk umí alespoň v základech SQL, tak napíše souhrný report, který se generuje třeba 1s. A když to někdo píše v PHP přes různá spojovaná pole a formátování, tak to trvá třeba minutu.
Navíc databáze může používat snadno query cache, PHP nemůže, protože neví o změně dat.
Datum vložení: 25.1.2005 1:18:08
Sice se to tématu článku zas tak netýká, ale ...
Opravdu jsou nároky na výkon burzovních aplikací tak strašné, že se musí psát business logika v DB? (předpokládám, že nějaké validace apod. ) To mi přijde nešťastné , PL/SQL přece není žádnej jazyk, jak v něm chcete psát komponenty?, třídy??
...se mi zdá, že je to blbost... jen tak vyhodit business layer...
Datum vložení: 25.1.2005 9:10:39
Tedy s některými. Zejména ale nesouhlasím s tvrzením, že PHP5 není krokem správným směrem.
- Informaci o type hinting jsem uvedl výše.
- private, public, ... jsou podle mého názoru _velkým_ přínosem. Jednak Vás upozorní na Vaše vlastní chyby, jednak Váš kolega v týmu dobře vidí interface třídy (takříkajíc na první pohled).
- Výjimky. Chyby zobrazuje aplikace, protože ona jediná ví, zda a kam může chyby zobrazit (a je teď celkem nezajímavé, zda se o to stará komponenta pro práci s UI, nebo zda se prostě použije echo 'Chyba'). Jak předáte aplikaci chybový stav vzniklý v komponentě pro práci s DB? (vizte např. B. Stroustrup: The C++ Programing Language)
Změna tématu: Výkonnost, rychlost programovacího jazyka vs. rychlost vývoje aplikací.
Jazyk PHP není ideální z hlediska rychlosti provádění kódu. Java je na tom o poznání lépe. C++ je na tom ještě o trochu lépe. (s C# nemám praktické zkušenosti, ale předpokládám, že bude blízké Javě) C může být o malinko rychlejší a strojový kód bude zase o trošku rychlejší než C (pokud umí programátor dobře optimalizovat). Znamená to, že všichni píšou v low level jazycích? Ne.
Rychlost vývoje aplikace závisí na konkrétním případě, ale dá se obecně říct, že Java může být favoritem. PHP může být rovněž favoritem. I C++ může být favoritem. (bez důkazů, připadá mi to zřejmé)
Co použije programátor? Z jazyků, které zná (to je podstatné) vybere ten, který považuje za vhodný pro daný typ úlohy.
Z hlediska zaměstnavatele je levnější programátor, který píše slušně ve 2 programovacích jazycích, než ten, který píše slušně v (řekněme) 10. Přitom se asi shodneme na tom, že mnozí z nás mají zkušenosti s výrazně větším počtem jazyků (a leckerých jsou schopni programovat slušně). Tím, že je jazyk vhodný pro řešení většího množství úloh, zlevňuje vývoj aplikace.
(Omlouvám se za dlouhý příspěvek.)
Datum vložení: 25.1.2005 13:32:09
Ale vždyť netypovost proměnných a modifikátory přístupu k třídám jdou proti sobě!
Netypovost a "vše je public" nijak nehlídá programátora, u menších programů, kde programátor typy a přístup "uhlídá sám" je to rychlejší.
Typy proměnných a private, public naopak "kontrolují" programátora, umožňují snáze pochopit kód i někomu jinému.
Tak jak může být pro jeden program jedno výhoda a druhé neváhoda? V čem je výhodné, když kompilátor/interpret "kontroluje" programátora někdy?
Datum vložení: 25.1.2005 15:39:57
Řekl bych, že vlastně říkáme to samé jinými slovy. (Pozn.: Vaše předposlední věta je v rozporu s "... je to rychlejší.")
Předně bych rád řekl, že "vše je public" není má oblíbená filosofie práce. Modifikátory přístupu (private, atd.) Vám, coby programátorovi _umožňují_, abyste si způsobil, že budete kontrolován (kompilátorem, interpretrem). Ale ani jejich existence nezaručuje, že se této kontrole podvolíte (i v Javě můžete teoreticky označit všechny členy třídy jako veřejné a napsat to jako nějaké domácí zvíře - jistě, proč byste to dělal...). Myslím, že v tomto si neodporujeme.
Teď type hinting. Kdysi jsem měl trochu problémy si na tu netypovost zvyknout, protože jsem předtím používal C++ a typovost mi vyhovuje. Také proto se mi type hinting v PHP5 zdá být krokem správným směrem (a v tomto smyslu jsem se snažil vyjádřit nesouhlas s článkem, v němž se tvrdí, že nedošlo ke skutečnému pokroku - teď zjednodušuju pro stručnost).
Na druhou stranu, neuvedení typu při deklaraci proměnné asi není zásadní problém. Pokud do proměnné vložíte float, zpravidla ji jako float používáte (třebaže to není vidět na první pohled, což může být pro někoho dalšího nepřehledné). Pokud je třeba přetypovat na TridaA, tak někde explicitně přetypujete a výsledek uložíte do jiné proměnné. A připadá mi celkem zanedbatelné, zda to provedete voláním typecastFromFloat2TridaA(promenna), nebo zda je to konstrukcí promenna + "". Jde jen o zvyk.
V PHP můžete do jedné proměnné uložit postupně hodnoty různých typů. Nedělám to a mám pro to své důvody. Pokud by to udělal kolega, po kterém bych to pak měl spravovat, tak si to s ním dojdu vyříkat. Neschvaluju to. Ale je to vlastnost jazyka. Umím se tomu vyhnout. Jinými slovy - není to pro mě dostatečně odpudivá vlastnost, abych kvůli ní přestal PHP používat.
Víte, řada lidí, možná většina, žije v domění, že programovat v PHP je hračka, že to zvládne každý. A skutečně, většina běžných situací na osobních stránkách je pomocí PHP snadno řešitelná i pro laika. Napsat v PHP větší projekt ale vyžaduje po programátorovi disciplínu, zkušenosti a další ... jako v kterémkoli jiném jazyce.
Myslím si, že spory o to, který jazyk je lepší, nikam nevedou. Lepší je si sednou, prodiskutovat, co nám na tom kterém jazyce vadí a nevadí. O to se autor článku pokusil. Jen jsem měl dojem, že některá tvrzení by bylo lepší upřesnit. Naopak rozhodně není mým cílem někomu PHP vnucovat, ani si nemyslím, že je to nejlepší programovací jazyk (a takový neznám).
Datum vložení: 25.1.2005 14:33:27
Zajímalo by mě, co jsou podle autora "problémy, které sužují PHP mnohem palčivěji".
Je to snad údajná absence podpory různých kódování, kterou kromě knihovny iconv může zajišťovat také knihovna mbstring, která podporuje i přepsání základních funkcí pro práci s řetězci funkcemi této knihovny?
Nebo to je nejednotnost pojmenování funkcí, která bohužel vznikla již v dávné historii? Bylo by lepší spoustu funkcí přejmenovat a tím pádem se PHP 4 už v podstatě nikdy nezbavit? Nikdo by nepřepsal všechny projekty používající staré funkce a vznikl by chaos a reálná nemožnost PHP 4 časem odstřelit.
Co se výjimek týče, dá se souhlasit s tím, že se jedná pouze o započatou práci, ale jako krok nesprávným směrem to rozhodně nevidím.
Kritika rozšíření možností objektů mi přijde z celého článku nejabsurdnější. Objekty bez rozdělení alespoň na private a public jsou jenom batohy na proměnné a funkce. Udělal autor nějaký benchmark, který by ukazoval, že objekty v PHP 5 jsou kvůli novým vlastnostem mnohem pomalejší než ty staré? V článku to není nijak zmíněno, pouze se tak nějak předpokládá, že to přece zákonitě musí být pomalejší. Ale ono nemusí...
Datum vložení: 25.1.2005 19:09:30
Nemam pocit ze by se autori PHP pokouseli srovnavat PHP s C# nebo Javou, mam pocit, ze se o to pokousi autor a asi z duvodu nepochopeni techto jazyku, vic k tomuto clanku snad skutecne nejde napsat. Zase jsem se jednou pobavil nad 'odbornikem'. Neni skutecne nic jednoduzsiho, nez si vystavet chybnou premisu (PHP se snazi nacpat na misto C# a Javy) a pak dokazovat, jak je spatna :)
Brona
Datum vložení: 26.1.2005 0:01:16
Zvláštní je, že právě do té oblasti se PHP cpe samo (třídy, viditelnost metody, vyjímkový aparát...), ačkoli jinak na to jazyk moc předpoklady nemá.
Datum vložení: 27.1.2005 9:29:51
To je mi ale zajimava myslenka :) a ja si nivne myslel, ze objektove programovani je univerzalni (obecna) technologie programovani, ale videtelne je to technologie jenom pro Javu a C#...
BTW. jake predpoklady musi podle Vas jazyk splnovat, aby mohl implementovat podporu objektu? :):)
Brona
Datum vložení: 27.1.2005 12:47:16
Spoustu requestu na (evidentne) "java-like" featury Zend odmita prave s oduvodnenim, ze to odporuje filozofii PHP a ze PHP neni & nikdy nebude Java. (Napriklad inner classes, o ktere jsem skemral, dale typovou kontrolu parametru funkci na urovni primitivnich typu apod (tedy ne pouze class-type hinting) atd.)
Datum vložení: 25.1.2005 21:20:18
Nejdrive bych se trochu podivil nad nacasovanim tohoto clanku - myslim ze na ROOTu probehl flamewar na toto tema jiz hodne davno. No ale to je jedno, nechci tim vylozene rict, ze takovy clanek nema smysl. Co se tyka toho objektoveho modelu, tak bych ty zmeny z hlediska navrhu jazyka oznacil spise za prinosne i kdyz nevim co vedlo autory k poruseni te zazite konvence: nazev konstruktor = nazev tridy. Asi je to jen takovy vzdor a rebelie :) K nazvu standardnich fci neni co dodavat. Proste kdyz to takhle udelali na zacatku... Jediny co me napada je, ze mohli vytvorit aliasy k funkcim, treba s CAMEL notaci a stare nazvy by pro zpetnou kompatibilitu zachovaly. Ty vyjimky je podle me trochu fiasko, kdyz nemaji podporu ve standardnich fcich. (Co si clovek nevyhodi to se nevyhodi :-). Zaverem bych jen dodal, ze nejsem tak skepticky jako autor clanku. Ja osobne neznam presne ambice tvurcu PHP, takze to komentovat nehodlam. Proste myslenka tech zmen neni spatna, jen to provedeni neni v nekterych pripadech uplne zdarile (vyjimky) a celkove ty zmeny nejsou takove, ze by jiz melo smysl srovnavat PHP s Javou a .NET. Srovnavat to snad lze jen z hlediska pouziti (kdy co pouzit), ale srovnavat tyto technologie jako takove je bezpredmetne....zatim :o)
Co me na PHP chybi je poradne IDE - slysel jsem o PHPeclipse, musim vyzkouset. Dale by me bylo smypatictejsi, kdyby uz PHP standardne obsahovalo objekty a ne funkce. Napr. $q = new query() $q->execute atd. takhle clovek musi tvorit sam, nebo includovat 3rd-party-code :)
Datum vložení: 26.1.2005 5:23:45
Priste by to chtelo aby clanek at uz o cemkoliv psal nekdo, kdo tomu aspon trosku rozumi a ne ten, kdo zde chce delat reklamu "konkurenci" a argumentuje nesmyslama.
Datum vložení: 26.1.2005 9:47:40
Java neni konkurence PHP. Nevim, jak .NET, ale taky bych rekl ze ne. Zvlaste, kdyz .NET je komercni vec ze ?
Datum vložení: 26.1.2005 13:59:09
To neni pravda, .NET, presneji C# a CLR jsou ECMA standardy a jejich implementace (zdarma) jsou napr. Mono projekt (viz. <a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://www.mono-project.com)' target='_blank'>http://www.mono-project.com)</a> a nebo <a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://www.dotgnu.org' target='_blank'>http://www.dotgnu.org</a>, ktere bezi na BSD, Linuxu, Windows, Unixy, Macove atd.
Datum vložení: 26.1.2005 14:53:16
Navíc zdarma je i základní řešení od MS: běhové (.NET Framework) a i vývojové (WebMatrix) prostředí.
Datum vložení: 26.1.2005 16:12:35
Presne tak a nyni s novou verzi SQL Serveru 2005, noveho Visual Studia a take noveho .NET Frameworku budou vysoce kvalitni nastroje uplne zadarmo. Vice zde:
<a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://lab.msdn.microsoft.com/express/' target='_blank'>http://lab.msdn.microsoft.com/express/</a>
nebo skvely nastroj na webovy vyvoj:
<a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://lab.msdn.microsoft.com/express/vwd/default.aspx' target='_blank'>http://lab.msdn.microsoft.com/express/vwd/default.aspx</a>
Sice jsou to zatim bety, ale fakt to jsou uz ted vynikajici nastroje a budou k dispozici behem tohoto roku.
Datum vložení: 26.1.2005 19:22:36
S těmi superlativy bych byl opatrnější, pokud to spojujete se slovem "zadarmo". Protože "zadarmo" je beta a navíc značně ořezaná, určená pro začátečníky. I kdyby byla zadarmo i ostrá verze, zaručeně bude jednak nepoužitelná pro vážněji míněnou práci, jednak licenční podmínky nebudou umožňovat komerční využití. Pro vývoj webu navíc podle FAQ použitelné nebude vůbec:
<I>What types of applications can I build with Visual C# 2005 Express Edition beta?
You can build Windows Forms, console, and class library applications.<I>
Tohle všechno tu už bylo několikrát, vždycky tu byly superlevné starter verze, které člověka navnadily a pak ho při stoupajících nárocích donutily zaplatit pár desítek tisíc za plnohodnotné vývojové prostředí. Očividně jim stejně vždycky někdo naletí...;-)
Datum vložení: 26.1.2005 19:25:07
Ksakru, vždyť jsem tu italiku uzavíral!
Redakce, prosím prosím, udělejte náhled a validujte výstupy. Zvládne to každý XML parser, projekt HTML Tidy je taky výborný. Nebo alespoň udělejte před uložením náhled, ať si to člověk může zkontrolovat...
Snad se mi to teď povede ukončit </I>
Datum vložení: 26.1.2005 19:28:53
A prd. :-((
Na webu věnovaném internetovým aplikacím tohle potěší. Přitom co si pamatuju, nejsem první postižený. Holt kovářova kobyla chodí bosa, znám to z vlastní zkušenosti ;-)
Tímto prosím někoho kompetentního, aby to narovnal, když už to nemůžu udělat já...:-/
Datum vložení: 26.1.2005 19:30:55
ještě </I> jeden pokus.
Datum vložení: 26.1.2005 22:05:41
Tohle je typicky FUD. Rikam zcela jasne, produkt Express je zdarma v beta a bude zdarma i v ostre verzi a aplikace v nem vytvorene budou a jsou urcene pro komerni nasazeni a maji plnou licenci. Je to plnohodnotny nastroj, kteremu ale budou chybet "enterprise" prvky jako je napr. architektonicke modelovani aplikaci nebo tymovy management vyvoje.
Jinak pokud byste nechtel cekat na ostrou verzi Visual Studia 2005 Express, ktera bude zdarma, tak uz dnes mate dalsi produkt zdarma - je to WebMatrix (viz. <a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://www.asp.net)' target='_blank'>http://www.asp.net)</a>, coz je Visual Studio s prvky pro vyvoj webovych aplikaci (opet tam nejsou enterprise prvky jako je obfuskator, profiler, SourceSafe atd.). Jinak tohle vse jsou plnohodnotne produkty.
Takze to jen tak pro uplnost, aby se tu nesirily famy a nepresnosti.
Datum vložení: 27.1.2005 22:34:58
No, nevím, vycházel jsem z informací na <a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://lab.msdn.microsoft.com/express/faq/default.aspx#vcsharp' target='_blank'>http://lab.msdn.microsoft.com/express/faq/default.aspx#vcsharp</a>, kde se jasně píše následující:
<I># Who is Visual C# 2005 Express Edition beta intended for?
Visual C# 2005 Express Edition has been built with the student and non-professional developer in mind. Visual C# 2005 Express Edition includes many of the same features found in the Visual Studio 2005 Professional Edition, but is also simplified to make it easier to get started with application development.</I>
a také
<I>The Express products are an expansion of the Visual Studio product line to include lightweight, easy to use, and easy to learn tools for hobbyists, enthusiasts, and students who want to build dynamic Windows applications, Web sites, and Web services.</I>
Z toho mi vycházelo, že se jedná o ekvivalent samostatných nástrojů typu Visual C# .NET, nebo o ekvivalent Visual Studio Academic. V obou případech jde o nástroje pro výuku nebo pro amatéry, těm kdo to s psaním aplikací myslí vážněji to sotva postačí, tam to chce minimálně Professional verze.
Pokud máte nějaké jiné informace, dejte sem link. Osobně se mi po dřívějších zkušenostech nějak nezdá, že by MS dával zadarmo něco, k čemu by nabízel ekvivalentní verzi za peníze, dosud se tak obvykle nechoval. Leda že by už tlak alternativních nástrojů byl tak silný...?
Jinak je mi to vcelku jedno, momentálně jsem z důvodu portability přešel na Javu poté, co mě přestalo bavit čekat, až se Mono dostane z praktické beta fáze (protože to, jak funguje teď, rozhodně nelze označit za ostrou verzi, bez ohledu na číslování verzí) do použitelného stavu. Takže svoje zakoupené VS už používám jen pro úpravy starých projektů...
Datum vložení: 27.1.2005 23:21:32
PS: Jenom doplním - pokud používáte slovo FUD, raději to podepřete argumenty. Já se to pokusil udělat. Pokud jsem se někde mýlil, milerád se vám omluvím, že jsem znevažoval vaše slova. V opačném případě pro mě vaše výroky mají - když to řeknu slušně - nulovou hodnotu. A říkám upřímně, že nemám rád, když někdo bez důvodu tvrdí, že lžu. Před dvěma sty lety bychom to asi řešili soubojem za úsvitu, teď si jen myslím svoje.
Datum vložení: 30.1.2005 7:11:03
Hmm, tohle zni jako velmi ferovy a sluzny prispevek. Ja se omlouvam za slovo FUD, je to Vas nazor a ja jej plne respekutuji.
Co se tyka Expressu, jak jsem rekl, budou zdarma a jsou to plnohodnotne vyvojove nastroje, vim to 100% a totez, co se tyka licenci na vyvoje plnohodnotnych komernich aplikaci.
Za sebe pak mohu rici, co uz jsem tu jednou psal. Java a .NET jsou vynikajici platformy a idealni je vyuzivat je obe, lze snadno demonstrovat slabiny Javy a take .NET, a proto nemam rad, kdyz nekdo rika, ze jen Java a jen .NET je nejlepsi. Ani jedno neni pravda a svedci to obvykle o tom, ze nema dostatecne znalosti obou platforem (to nemyslim na Vas, to pisi vseobecne). Proto zaver za me je, ze je nutne mene "IT nabozenstvi" a vice studovat a vice znat. Kazdopadne Vam diky za solidni prispevky.
Datum vložení: 30.1.2005 9:43:24
Co se týče srovnání těch dvou platforem, nemám důvod s vámi nesouhlasit. Obě mají svá plus i mínus, jsou věci, které má lépe vychytané .NET, naopak jsou věci, ve kterých je lepší Java. Já osobně jsem .NET opustil v podstatě pouze kvůli přenositelnosti: dlouho jsem počítal s tím, že využiju Mono, proto jsem se také svého času dost intenzivně zapojil do jeho betatestování včetně posílání patchů. Problém byl v tom, že dokud to bylo označováno jako betaverze, byl jsem smířen s tím, že narazím na nějaké ty obtíže. Pokud ovšem něco označím za ostrou verzi, měl by tomu odpovídat stav projektu. Naproti tomu Ximian se přes jedničku přehoupl dle mého soudu pouze proto, že už mu bylo blbé znovu posouvat termíny roadmap. A jestliže se díky opravám i do ostré verze zanášejí neustále nové bugy, je to na pováženou. Stále tam bylo množství nedodělků, stále tam byly problémy - které jsem posléze už přestal reportovat, protože jsem tím trávil podstatně víc času, než mi bylo milé. Ta poslední kapka pak u mně bylo to, když mi po upgradu na verzi 1.0.2 přestala za určitých podmínek fungovat kompilace ASP.NET šablon na mém osobním pidiwebu, neboť parser přestal být schopen převádět stringy na čísla. Nedokážu si představit, jak v této situaci použít Mono v ostrém provozu na serveru, kde o něco jde (čili u zákazníka). A pokud se nepletu, ostatní projekty přenášející .NET na jiné platformy se přenosem assembly System.Web nezabývají.
Čili nikoli náboženství, pouze praktičnost - v mém případě totiž bude přenositelnost do budoucna hrát čím dál větší roli a obávám se, že od .NETu se jí ještě nějakou dobu nedočkám...:-/
Datum vložení: 26.1.2005 11:24:26
byl bych opravdu vděčný za článek či seriál o vyvíjených frameworcích pod PHP aneb jak programovat věci systémově pod PHP
Datum vložení: 26.1.2005 19:10:59
zacni tady <a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://www.whoa-framework.org' target='_blank'>http://www.whoa-framework.org</a> :)
Datum vložení: 27.1.2005 8:40:12
Doporučuji mrknout se na <a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://www.xisc.com/' target='_blank'>http://www.xisc.com/</a>
A velmi dobré jsou smarty.php.net. Smarty mají tu výhodu, že se přenáší prezentační a nikoli aplikační logika. A upřímně největší znovupoužitelnost je právě u prezentační logiky.
Datum vložení: 26.1.2005 12:20:56
Souhlasim s nekterymi vyroky autora, ale ne zcela:
- cim mne PHP5 zklamalo jsou problemy v praci s ORACLE databazemi, potykame se s nimi uz dlouho, a krute
- podpora vyjimek je skutcne nedokonala, ovsem aspon neco, a to ze ma PHP mraky extenzi od ruznych autoru a tam dosud vyjimky nejsou - domnvam se, ze to je pochopitelne
- posledni veci co me mrzi, jsou problemy ktere se projevuji tzv " divnymi chybami", a aplikace vyborne fungujici na PHP 5.0.2 dela na 5.0.3 "divne veci", pada pokazde na jinem radku => evidentne nejake problemy s pameti, coz je ovsem ponekud "confusing"
Jinak je tam ale opravdu par moc sikovnych novinek, ktere jsou rozhodne prinosem!
Datum vložení: 26.1.2005 16:31:57
Mohli by ste blizsie specifikovat chyby pri praci s Oraclom? Ja som sa uz dlho s nicim takym nestretol ...
Datum vložení: 27.1.2005 14:11:18
Rad - na Linuxu nereprodukovatelne, ale na Sun Solaris na Sparcu na PHP ve verzi 5 velky problem s perzistentnimi spojenimi, bez ohledu na verzi Apache ci PHP (v ramci petkove rady). OCI klient je komercni software, bohuzel, ale se starsim PHP jede vse v poradku a od verze 5 se objevuji pady ve velkem mire - nejcasteli pri uzavirani perzistentnich oci sessions. tento problem jsme nevyresili ani po konzukltaci s autorem/soucasnym spravce OCI extenze ani s jednim clenem vyvoje OCI klienta z Oracle Australia :-((
Datum vložení: 28.1.2005 11:47:32
Podle mého mínění PHP ještě neprospívají další věci. Jednak často děsně dlouhé adresy, v poslední době to příšerné spamování návštěvních knih a tak.
Možná někdo za chvíli přijde s něčím jednoduchým, bez třech spoust funkcí, něco jako ořezaná Mozilla - Firefox, kde bude to základní nejpoužívanější a bude to další hřebíček do rakvičky.
Datum vložení: 28.1.2005 12:09:06
Jak prosim souvisi dlouhe adresy a spamovani navstevnich knih s PHP? Leo
Datum vložení: 31.1.2005 12:45:45
No na niekoho to bolo treba zvaliť a PHP bolo tak pekne na rane ;-P
Datum vložení: 30.1.2005 21:13:49
Pochop, PHP běží jako něco, co "parazituje" na souborech žádaných klientem. (Nenapadá mě bližší srovnání.) PHP si bere informace od klienta, které by server normálně ignoroval a pak něco udělá s daty, které by server normálně poslal na klienta. Takže je fuška do toho prostoru komunikace vrámci starého HTTP nacpat <I>vůbec nějaká data</I>.
K tomu spamování - to není problém PHP jako takového. Totéž se ti může stát (a pravděpodobně stane :-)) i na webu generovaném servletem. (BTW; mám za to, že tam se taky nevyhneš dlouhým adresám. :-))
---
Do pranice:
Já osobně vidím PHP jako dost silný nástroj pro tvorbu <B>webových aplikací určených k prezentaci informací</B>. Tak ostatně bylo i myšleno, nebo ne? Pochybuji, že by na tomto poli nebylo rovnocenným konkurentem Javy. Ale přesto si myslím, že v podobě, jakou má dnes, se udrží pouze u malých aplikací, řekněme na úrovni diskuzí, poskládaných stránek, maximálně menších CMS.
Jak už někdo poznamenal (omlouvám se - přehlédl jsem jméno), PHP nemůže vypustit, ani přejmenovat staré věci, protože by zůstalo na úrovni 4.2 - nikdo by staré aplikace nepřepsal => poskytovatelé by neupgradovali.
Tudíž si myslím, že by bylo praktické začít vyvíjet novou verzi PHP jako novou aplikaci, která by se okleštila o neobjektové konstrukce a knihovny a do které by se doplnila pořádná podpora objektů, a pomůcek včetně hierarchie výjimek. Ta by se postupně prosadila vedle původního PHP, které by pak mohli časem zatratit úplně. A nemyslím, že by se nenašlo dost odvážlivců, kteří by s tím pomohli...
Datum vložení: 10.2.2005 10:08:44
Nevíte někdo jestli se někam na MySQL server ukládají neprovedené dotazy INSERT?
Datum vložení: 12.2.2005 18:11:05
Spor mezi uživateli Javy a PHP je naprosto zbytečný. Pokud vím, PHP je "PHP: Hypertext preprocessor". Tudíž používat jazyk, který původně byl určen jen na lehkou dynamizaci stránek jako jazyk na úplně všechno, mi připadá hloupé. Pokud budu dělat nějakou aplikaci, tak možná udělám uživ. rozhraní v PHP (možná taky ne, existuje JSP, Velocity, cokoli), ale samotné zpracování dat udělám třeba v Javě, nebo to napíšu v C++ když budu hodně trvat na rychlosti. Jako příklad toho, že v PHP by se nemělo dělat všechno je extrém, kdy vyberu data z tabulky a veškeré operace, které by zvládlo třeba JOIN nebo ORDER BY v SQL píšu v PHP znovu. Pokud budu dělat operace nad databází, tak kontrolu integrity dat, třídění apod. budu dělat přímo v SQL. Moderní SQL servery podporují i uložené procedury, trigery, atd., takže udělat operaci s daty, kontroly, dotazy, atd. je otázka databáze, komunikace s databází a datovou vrstvou je otázka nějakého programu (ať už v Javě, Perlu, Pythonu, C++, ...) a zobrazení už nechat na PHP, JSP nebo něčem jiném. Každopádně každý programovací jazyk má to svoje a známkou dobrého programátora je vybrat na jednotlivé části aplikace to, v čem půjdou udělat nejsnáz, protože to usnadní ladění, testování a správu.
Datum vložení: 25.2.2009 20:32:59
zeptám se vás asi tak... znáte nějakého programátora který je špičkový v C++ JAVA PHP SQL ???? ... většina mých kolegů umí všechny tyto jaziky špičkově + nějaké další doplňky ... jenomže problém je stěmi nově příchozími .. oni umí napr jenom PHP + JS .. nebo JAVA ... nebo C++ C# atd.... prostě to neumí provázat .... o hlubší znalosti SQl jsem radši ani nemluvil ....
Datum vložení: 25.2.2009 20:28:41
..... ani v dnešní dobe jsem nevidel ovladac vetsí jak 1.5 MB ... a to musel mít přístroj sakra složitou konfiguraci.... těch dalších 350 jsou utility které nerezjedente (v dnešní době) ma 160 MHz...a 64 MB RAM ... jsou to ovšem jenom utility na ten jeden malinkatý soubor který potřebuje k provozu (mám to odskoušené) 50 MHz a 16 MB RAM v plném vitížení ..... ta náročnost na HW je kvůli lidem ... oni pořád chtějí jednoduchost na úkor spolehlivosti (viz Windows)... bohužel v tom pracuji a když za vámi přijde šéf že tenhle komplet funkčního celku musíte mít za tři dny, a nejedná se o i+i=3 , tak to se prostě nedá napsat -- pro spokojenost zákazníka a co nejmenší HW zátěže .. (zase viz win ... Vista je toho dukazem .... na staré jadro nalepili milion efektů a pak se divili že na to musí mít v PC , 2GB RAM , pro hladký průběh)....