Vlákno názorů k článku Na co si dát pozor při práci s objekty v PHP od Marek Slapak - Ja nevim, ale delsi dobu delam web logiku v...
-
Článek je starý, nové názory již nelze přidávat.
-
Marek Slapak (neregistrovaný)
Ja nevim,
ale delsi dobu delam web logiku v jsp a servletech (java), k dispozici mam celou palbu java platformy, lita to jak strela, je to pohodlny a nemeni se to tak, abych neco z drivejska musel prepisovat (specifikace). Navic mam k dispozici plnohodnotny OOP a vse funguje jak ma :-)
Nechci rozpoutavat flamewar, to ne, ale nemuzu si pomoc, ale psani i jednoduchych webovych veci mi porad pripadne snazsi v jsp (napriklad pri pouziti tag libraries ani ty javy covek moc nenapise)... kdyz k tomu pripoctu standardizovany JDBC rozhrani na pristup k databazim a nad nim postavene mechanismy poolovani spojeni, ruzne cache na opakovane pouzivane objekty, abstrakci DBMS pomoci ORM metod (object-relational mapping) jako je treba www.ibatis.com, ruzne mechanismy umoznujici psat komplexni interakci s uzivatelem pohodlne a mocne (MVC - napr. Jakarta-Struts, SUNacky Java Server Faces, nebo Jakarta-Tapestry, atd..)
Bohuzel jedine mluvi proti - a to nedostatek hostingu, kde je k dispozici jsp&servlet konteiner, ale jinak porad nechapu, k cemu vlastne PHP je :-) nejak kdyz na nej koukam (laicky) tak mi nepripadne, ze by bylo nejak zvlast jednodussi, nez java web servrovy technologie,
ale na druhou stranu je _dobre_ ze je moznost volby a kazdy si muze zvolit to, co mu vyhovuje, takze nikomu nic nechci hanit ! -
barney (neregistrovaný)
ono php vzniklo v case, ked vacsina server-side aplikacii bolo pisanych v perli, mod-perl ci mod-fastcgi boli experimentalnym dobrodruzstvom a java ... sorry, ale to uz zamestnat typka co bude rucne odpovedat na vsetky requesty zarucovalo rychlejsiu odozvu.
php je podla mna vhodne na jedno-dvoj strankove blbosti typu registracny formular.
java je celkom slusny jazyk na vyuku principov objektoveho programovania
osobne uz programujem takmer vylucne len v perli ... kto ho ovlada vie preco, kto nie, moze len ticho zavidiet :-))) -
barney (neregistrovaný)
ja si myslim, ze ziaden jazyk nie je vhodny pre weby, ale to je o inom :-)))
weby su piplacka.
ak mam robit web, tak radsej pouzijem kniznice:
HTML::Template (na oddelenie vykonneho kodu a samotnej stranky ... tuto kniznicu pouzivam aj neHTML aplikacie)
CGI::Application (mierne upravenu mojou triedou)
Class::DBI (objektove zapuzdrenie databazovych pristupov)
Class::DBI::AbstractSearch (bohuzial neobjektove, ale uzitocne rozsirenie kniznice Class::DBI)
a co sa tyka write-only programovania ... zalezi od cloveka, co program pise, ale osobne by som za take daco postavil typka k mure -
agent (neregistrovaný)
Používání knihoven se rozumí samo sebou. O tom se není potřeba vůbec bavit.
Ale i v závěru knihy pan Satrapa ve své knížce "Perl pro zelenáče" píše v kapitole o CGI, že je zajímavé, že Perl se prosadil v oblasti, na co je nejméně vhodný, a to na webech.
V zásadě prakticky do jednoho mi odborníci na Perl sdělují, že nepovažují Perl za jazyk vhodný pro weby. Píšou to v knihách, říkají mi to osobně.
Já si osobně myslím, že pro weby vhodné jazyky existují. Osobně se domnívám, že PHP a pravděpodobně i Perl je pro použití na jednoduchý web, a je to silný kompromis. -
Marek Slapak (neregistrovaný)
:-) nevim, ale asi budu drsny, ale perl .... nepopiram, ze moznosti tohodle jazyka sou impozantni, ale psat v nem neco komplexnejsiho asi musi znamenat dost notnou davku masochismu..
Ad java: soude podle ty vtipny reakce s typkem na requesty: videl si ji nekdy bezet na serveru (napr. apache tomcat) ? Zejmena pak pod Hotspot-VM/server runtime ? Pokud ne, tak opravdu vrele doporucuju, mozna budes hoooooodne (nevim jestli mile, nebo nemile), ale kazdopadne prekvapenej budes ! :-)
A jeste k tomu perlu:
tak pokud by slo o procesovani pres Regexpy, tak ve svete Javy mame napr. apache regexp, a pokud by slo o perlovy konstrukce, awk-like procesing, atd, tak mame treba apache-ORO
Mno a ucebni pomuckou na uceni se OOP byla java kdysi davno, to ano, ale dneska je synonymem platformy pro budovani komplexnich enterprise informacnich systemu, coz asi taky o necem svedci
Ale i tak musim uznat, ze obdivuju, co sou lidi v schopny v perlu udelat, ale opravdu - i kdyz je urcite genialni, tak si ale neumim predstavit , jak by se na nem budoval IS vcetne centralni spravy uzivatelskych prav a roli, vcetne interakce s okolim, apod.. i kdyz verim, ze modulu je pro nej hodne, ale precjenom, objektove tridy jsou objektove tridy a na java platforme je taky primo ukrutnej vyber vseho moznyho a nemoznyho,takze bych to uzavrel podobnou vetou jako ty -
- osobne uz temer vylucne programuju v jave ... kdo ji ovlada vi proc a kdo ne, muze jenom tise zavidet :-)) -
barney (neregistrovaný)
viem, co dokaze java, myslim, ze som sa v nej naprogramoval dost.
nikdy nekritizujem nieco co nepoznam ci neovladam.
princip OOP a programatorskej discipliny v jave i v perli je rovnaky
maju rovnako struktorovany package management
pre a proti vravia len male rozdiely:
- perl ma tri zakladne datove typy vzajomne na rovnakej urovni.
java ma blizsiu specifikaciu skalarnych datovych typov
velke minus ... zakladne datove typy NIE SU objekty, co vyzaduje pridavnu programatorsku disciplinu
- perl ma funkciu/metodu AUTOLOAD ... ak je definovana, je to vseobecny handler pre nedefinovane, ale volane metody ... uzitocna vlastnost napr pri implementacii vzoru AbstractFactory
je zbytocne sa bavit o faktoroch stabilita, vykon, v dnesnej dobe hlavne na tom druhom nezalezi.
co zalezi je rozdiel v narocnosti na ludske zdroje ... a to si dovolim tvrdit, ze perl je v sucasnej dobe najvyhodnejsia platforma. -
Marek Slapak (neregistrovaný)
Mno,
souhlas, ta zalezitost s primitivnimi typy v jave, to je rekneme krapet nedotazenost, nicmene v 1.5 se to bude resit autoboxingem... nerikam, ze je Java dokonala, ma svoje mouchy .
- Perl do detailu neznam, to priznavam, ale co se tyce abstrakce, tak u javy si hodne cenim technologii vyuzivajici Reflection / Introspection a vubec celkove ten ohromnej ranec OSS api a reseni, ktery je coveku k dispozici. Tim nesrovnavam s Perlem, jenom chci rict, ze to je faktor pro mne dulezity - odrazejici se mj. na produktivite prace
Co se tyce narocnosti na lidske zdroje, nevim, u Perlu nemuzu hodnotit, ale kdyz se vratim zpet treba k ty bezpecnosti a standardum:
ma Perl jako "platforma" takovy veci jako je JAAS, JMX, ,JSSE, JCA, JNDI, JCE, RMI, JMS, EJB, JSP&Servlet, atd. ? Existuje neco jako JDBC standard pro pristup k DBMS zdrojum, dle ktereho snad ani neexistuje DBMS, ktery by minimalne jednim JDBC driverem nedisponoval (dokonce i M$ SQL ma jdbc 2.0) ? Existujou v perlu implementace mechanismu jako je treba poolovani dbms relaci, ORM, .. ?
-existujou pro perl aplikacni servery a frameworky, neco ve stylu JSP&Servlet, EJB konteineru, nebo Avalon Frameworku ?
- jaky sou schopnosti a moznosti prace s XML ? ruzne metody XML-RPC ? neco jako JAXP, SAAJ ?
Tim ti nekritizuji tvoji a tvou osobni volbou zvolenou platformu, to v zadnem pripade, spis se jenom ptam, protoze nemit k dispozici implementace alespon casti standardu, co jsem vyse jmenoval, no nevim, nevim jaka by byla produktivita prace delat vsechno od piky ... vzhledem k oblibe verim, ze je pro Perl k dispozici halda modulu, ale sou k dispozici taky nejaky komplexni standardy nebo patterny (mysleno zejmena v stylu EJB patternu) ? -
barney (neregistrovaný)
skratky ktore ste uviedli maj vzdy v sebe jedno velke J (zeby Java?) :-))
ale podobne mechanizmy s inymi nazvami su k dispozicii i v perli
kompletny zoznam dokumentacie kniznic perlu je na search.cpan.org,
z mnou pouzivanych kniznic mozem vymenovat:
RPC::XML pre implementaciu client i server XMLRPC aplikacii
XML::DOM (snad netreba vysvetlovat)
XML::XPath (hmm, to P urcite neznamena Perl :-))
XML::Parser (SAX parser, konkretne expat)
DBI pre pristup k databazam (ekvivalent JDBC)
Class::DBI pre objektovy pristup k databazam
aplikacne frameworky v perli sa nenazyvaju nejakym extra honosnym nazvom, vyuzivaju reflexivne vlastnosti perlu (ktore su imho silnejsie ako vlastnosti javy)
uznavam, ze java ma tiez svoje vyhody.
hlavnou moze byt to, ze programatori v jave su lacnejsi :-)
perl je totiz jazyk, ktory jedine co vyzaduje od programatora, ze vie co robi a ze ma vnutornu disciplinu (co podla mojich skusenosti su vlastnosti u programatorov sa zriedkavo vyskytujuce) -
Jirka Hradil (neregistrovaný)
'java ma blizsiu specifikaciu skalarnych datovych typov
velke minus ... zakladne datove typy NIE SU objekty, co vyzaduje pridavnu programatorsku disciplinu '
JIRKA: Proc tedy v Jave nepouzivate objektove reprezentace primitivnich datovych typu, napr. java.lang.Integer ? :) -
barney (neregistrovaný)
preco sa v jave nepouziva napr java.lang.Integer?
pretoze obycajne scitanie by vyzeralo nasledovne:
Integer result = new Integer (a.intValue + b.intValue);
co je s prepacenim vacsia uchylka ako m$
pamatam si na "nastup" javy, ked autori vyhlasovali, aky genialny jazyk oni vymysleli, aky perspektivny
osekali C++, vyhodili veci ktore nepouzivali (ci ktore vyzadovali programatorsku disciplinu) a vytvorili jazyk pre drevorubacov. -
Jirka Hradil (neregistrovaný)
Tak ted nevim, co byste si presne predstavoval. Chcete primitivni datove typy? Tak je pouzivejte takove, jake jsou. Rad byste objekty? Mate je tam. Pokud chce zapouzdrit primitivni datovy typ, mate moznost. Pokud se vam nelibi pocitat s objektovou reprezentaci, tak si nestezujte, ze ji nemate. ;)
Jestli mate konkretni navrh, jak udelat v tomto smeru zmenu v jazyku Java, poslete ji do Sunu s kopii na me, chytri panove v Sunu to jiste uvitaji. Muj nazor je takovy, ze soucasne reseni je to naprosto dostatecne a velice chytre vymyslene. -
Jakub Hegenbart (neregistrovaný)
"zakladne datove typy NIE SU objekty, co vyzaduje pridavnu programatorsku disciplinu"
Ja tedy nevim, ale obtezoval jsem se cist manual a trosku experimnetovat a zjistil jsem, ze vsech osm primitivnich datovych typu a vsechna jejich mozna pole maji sve tridy. Takze to asi BUDOU objekty :)
Samozrejme - skutecnost, ze z nich neni mozne dedit (predpokladam, nezkousel jsem, ale asi to zadnym sebevice slozitym figlem nepujde) a ze je neni mozne predavat jako Object je trosku diskriminuje, ale objekty to zcela jiste jsou (alespon navenek). Zde je ovsem dobre pripomenout si zasadu Design Patterns, ze kompozice je flexibilnejsi mechanismus nez dedeni...
Je akorat smutne, ze zatimco C# se k moznosti dvou storage classes primo hlasi, Java o tom mlci (nebo jinak: kdyz integer ma svoji tridu a je tedy objekt, proc manual tvrdi, ze vsechny objekty jsou na heapu a spravovany GC, kdyz lokalni integer je na stacku a je "auto?" (po Cckovsku)). To je trosku nedusledne. -
jezovec (neregistrovaný)
tak si ale neumim predstavit , jak by se na nem budoval IS vcetne centralni spravy uzivatelskych prav a roli, vcetne interakce s okolim, apod..
ale samozřejmě že to jde, a není to tak těžký, chce to jenom přemýšlet a umět, oddělit data a jejich prezentaci a bussines logiku, stejně jako v kterémkoliv jazyce... mně se zase s perlem dělá líp než s Javou (programoval jsem v obou)
