Názory k článku Na co si dát pozor při práci s objekty v PHP

tohle ma byt oop? opravdu dobry ftip
a k posledni vete, ze to vylozene nestezuje objektove programovani - ne opravdu ne, zvyknout se da na vse, ale pokud neni mozne zapouzdreni (odizolovani private atributu a metod), tak k cemu to vlastne je?

mozna ze v php verze 10 uz se budou objekty chovat tak je ocekavano, ale to nezbyde chudakum vyvojarum nic jineho, nez to zase cele (po kolikate uz?) prepsat

no mozna je to trest za volbu tohoto "jazyka"

Jojo, PHP4 v zadnym pripade neni OOP, staci se jenom podivat na nemoznost rozliseni jestli promenna obsahuje objekt nebo referenci na objekt. A takovych veci je vic, ale prej PHP5 uz bude hodne lepsi na objekty, tak uvidime.

Ke skryvani promennych: ani by to nebylo moc super, protoze PHP (v4) jaksi nedokaze udelat $objekt->metoda1()->metoda2(), takze je nutne bud pouzit X promennych na docasne ulozeni objektu vracenych metodou1 a nebo, pokud metoda1 vraci objekt, ktery je nejakym zpusobem ulozeny v objektu $objekt, tak pristupovat primo na tu promennou. Az bude PHP umet tohle, tak muze skryvat promenne.

Jinak PHP ma rekl bych hodne bugu v docela zakladnich akcich, problem je, ze pro male skriptiky se asi moc neprojevi. Mam napriklad nasledujici kod
=====
class A {
var $ch=array();
function __construct() {
}
function A() {
$this->__construct();
}
}

class B extends A {
function B() {
echo gettype($this->ch);
parent::__construct();
}
}

$b=&new B();
=====

samozrejme takhle napsanej skriptik vypise typ "array()". V nasem programu (takovy trosku vetsi projekt) mi to normalne taky nechava v promenne $ch array, ale v urcitym pripade mi to tam nastavi kdo vi co a je tam "unknown type" (var_dump rika "&UNKNOWN:0"). Pritom kdyz do tridu A upravim takhle

===
class A {
var $ch=array();
function __construct() {
$this->ch=1;
echo "trida A";
}
}
===

tak se mi uz v konstruktoru B() vypise "array()" a pak se vypise text "trida A", cili staci pridat pouze kod na prirazeni do promenne a uz to uvlivni, ze pri vytvareni objektu (PHPckem) se vlozi spravne array do promenne $ch (ktery je pak samozrejme prepsan cislem 1). Proste docela takovej bordel.

Myslim, ze v dokumentaci se pise, ze k inicializaci promennych se mohou pouzit pouze konstantni vyrazy, coz funkce nejsou. Cili pokud inicializujete pomoci "array()", nedivte se, ze to bude delat skopicarny.

Výraz array() není funkce, ale jazykový konstrukt, jak se píše v dokumentaci, tudíž i tato námitka je trochu diskutabilní. Teoreticky by to tedy měl být skutečně konstantní výraz.

Já si spíš myslím, že prostě je PHP trochu nedomyšlené, a mnohdy ani PHP neví, kam co patří.

On totiž samotný PHP jazyk se mnohdy skutečně chová dost překvapivě. Sám jsem toho v PHP napsal hodně, a leckdy využívám věci z PHP až do vyždímání z poslední kapky. A leckdy chování PHP odhaduji stylem: "Kdybych byl autor PHP, tak bych asi tuto funkci napsal v C takto. A chovalo by se to asi takto." Tedy odhaduji vnitřní algoritmy.

Osobně považuji za nejlepší strategii nevyužívat PHP naplno. A vyzkoušení je k ničemu, protože to pak v jiné verzi PHP často funguje trochu odlišně.

Ach jo. Uz zase nekdo misinterpretuje zapouzdreni (a nejspise nejen to)...lidi, ten termin je preci o necem uplne jinem nez "private" a "public." Ostatne PHP neni samo, zadny jazyk, ktery podporuje "public" promenne (treba C++ nebo Java) nezapoudruje tak, jak by podle OOP mel (samozrejme z duvodu implementacni efektivity - to neznamena, ze jazyk je spatny - jen neni OO v tom nejprisnejsim slova smyslu)

Zajimalo by me jak se v PHP pretypuje z jednoho objektu na druhy. Treba z objektu Zidle na obecnejsi Nabytek. Pokud to nejde ztratil jsem posledni kapku v implementaci OOP v PHP 4.x

V PHP typy objektů de facto neexistují. Prostě objekt je halda atributů a halda metod. A název třídy je de facto jen skrytý atribut.

Takže přetypování není potřeba. Prostě tam dosadíte objekt jiné třídy, který má potřebné atributy a metody, dokonce nemusí být ani v dědické linii. A bude to fungovat.

Mě se to sice nelíbí, ale takto to je. Na druhé straně je to dost flexibilní. Dokonce si můžete vytvářet dočasné třídy, aniž byste psal kód.

pri ukladani objektov do session by som si daval dost pozor. podla mna to nie je dobry napad, lebo ... no nikdy som to neskusal, ale je to o atomickych operaciach podla mna ... tzn. do $a nahram objekt zo session, nieco v tom zmenim a ulozim naspat. toto je blbost, PHP to podla mna serializuje az na konci (po ukonceni spracovania dokumentu) tzn. ani praca nad $SESSION_VARS ci ako sa ten globalny hash vola nepomoze... (mozno) sumar: objekty v session radsej nie ...

Navic kdyz si vezmu, ze mam takovou zakladni strukturu jako je Tree v objektech a mam tam rodice a deti, pricemz samozrejme v tech rodicich a detech mam udelany reference na ty objekty, proste serializovat reference asi neni tak super a pri objektech bych rekl se budou reference vyskytovat dost casto, pricemz i cyklicky reference se budou vyskytovat dost casto (zvlast v ruznych seznamech), takze opet: serializace je dobra na male promenne a jednoduche datove struktury. A takhle to je podle me s celym PHP-na jednoduchy veci super, ale na nejaky slozitejsi veci nepouzitelne (at uz bugama, nebo zpusobem prace s promennyma atd).

Je to tak, PHP měl zůstat jednoduchým ale mocným skriptovacím jazykem. Tohle hraní na OOP je o nicem.

Ukladat objekty do session je mozne, pouzivam tento mechanismus delsi dobu. Nejde o to ukladat do session objekt po kazde zmene, ale pouze na konci skriptu, kde dale uz s objektem pracovat nebudu. Pokud mam na objektu naveseno "x" dalsich referenci na jine objekty a vim ze pri dalsim nacteni skriptu nebudu tyto potrebovat, PHP mi dovoluje selektivne urcit co nechci do session ulozit. Nebo jeste lepe je podridit design aplikace teto vlastnosti PHP.

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 !

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 :-)))

Napdá mě jediný možný důvod: protože je perl write-only, takže se nemusíte bát zcizení duševního vlastnictví :o)

Pod to se podepisuji ;-)))

Opravdu je Perl na weby tak vhodný? Mě několik profesionálové v perlu nezávisle na sobě sdělilo, že Perl nepovažují za jazyk vhodný pro weby. Vysloveně mě od toho zrazovali.

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

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.

Perl na weby relativne vhodny je, rozhodne bych netvrdil, ze je pro ne "nejmene vhodny". Na druhou stranu neni urcite hlavnim cilem perlu dominovat webum a uz jen proto naleznete pro web i vhodnejsi jazyky.

:-) 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 :-))

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.

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) ?

'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 ? :)

"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.

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)

Současný stav OOP v PHP mi také nevyhovuje.
Na druhou stranu je PHP tak vnitřně pružný jazyk (konstrukce typu: eval, $$, call_user_func, include v pomínce, textové klíče polí, funkce v proměnných), že si každý může naprogramovat takovou funkcionalitu svých komponent (zdůrazňuji komponent nikoli objektů) jenž mu zcela vyhovuje i bez OOP.

Robert

Ano presne tak , i velmi velke projekty jdou napsat bez OOP.

No to je fakt. Stejne tak jdou napsat stylem copy con program.exe :-)

:-)))))))))))))))))) MAS RECHT :-)))))))))))))))))

Jistě. Je ovšem všeobecně známo, že __opravdoví__ programátoři píšou stylem copy con program.zip.

:-)

/d

A to se netyka jen PHP. V jakemkoliv rozumnem programovacim jazyku muzete psat objektove i bez pouziti objektu. Napriklad takove GTK je objektove ze to vic nejde a je psane komplet v C (nikoliv C++).

i slapaci auto je v principu dopravni prostredek :-)

chci tim jenom rict, ze je IMHO skoda se o prinosy opravdoveho OOP zamerne a o vlastni vuli ochuzovat ...

Tohle nechapu. Co to je "opravdove OOP" v tomhle kontexu? Vzdyt zde uz padlo, ze GTK je plne (a to je dle meho soudu vyznam slova "opravdu") objektove...

Analogie: Kdyz mam uplne auto (tj. s motorem), mam chtit jeste "opravdove uplne" auto? Slapaci auto jiste neni "opravdove," ale prave proto, ze neni "uplne" z pohledu motoristy.

Je to jen slovickareni, pravda, ale analogii s autem bez motoru jste nakousl Vy :)

Riesenim je pri volani konstruktora priradovat vzdy referenciu. Inak sa instancia objektu kopiruje zbytocne hned po vytvoreni.
Oba uvedene priklady budu pachat co maju, ked sa $a = new... nahradi $a =& new...

Je pravda, ze OO model PHP je priserny, rovnako je priserna nexistencia jednotneho nazvoslovia rutin standardnych modulov a skutocnost, ze nie su implementovane ako triedy. Nad vsetkym potom treba vytvarat OO abstrakcie, ktore v Jave implicitne existuju. Kazdopadne, PHP je celkom flexibilny jazyk (beztypovost, asociativne pole ako primarny sposob tvorby struktur, ...) a pri slusnom navrhu a respektovani anomalii v nom mozno implementovat aj dost roziahle projekty s MVC architekturou a radovo stovkami tried /mam vyskusane (;/. Ale zacinat dnes novy projekt takeho rozsahu "from scratch" a zvolit PHP by som neodporucal.

Standartni moduly jako tridy ? Jen to ne. To uz by to PHP neslo pouzivat na nic - takhle ho alespon jde pouzivat kdyz se na objekty vykasles.

PHP od verze 4 prirazuje tak, ze $a=$b hodi do $a interne odkaz na $b a obsah se skutecne zkopiruje az pri modifikaci $a nebo ruseni $b apod. To plati i pri predavani promennych funkcim. Referenci pouzivejte pouze pokud ji skutecne potrebujete.

V pripade instancii objektov nemozem suhlasit.
V praxi je semantika nereferencneho operatora priradenia v PHP

O objektech v PHP4 se rozsahle psalo na rootu v serialu "PHP (v) objeti objektu", o novych objektech v PHP5 pak v serialech "Zaostreno na PHP" a "PHP po roce".

Zajimava vec je (a to me trochu mrzi), ze kdyz vyjde na rootu clanek, stale casteji se stava, ze diskuze pod nim se obrati v kecarnu o nicem, kritizovani vseho nebo zkratka flame-war. kde jsou ty casy, kdy byly diskuze konstruktivni a clovek se necemu priucil...

Kde jsou ty casy, kdy PHP bylo konstruktivni a clovek se necemu priucil... :)