ugrás a tartalomhoz

PHP-s kérdések tisztázása

Granc Róbert · 2003. Júl. 28. (H), 17.01
Sterling Hughes saját weblogjában szombaton megpróbált néhány, a PHP-vel kapcsolatos aktuális kérdést letisztázni. Ezek a PHP és a MySQL kapcsolatát, a PHP 5 hibakezelését (a try/catch rendszert) és az "egyedi tagok" ("private members"*) rendszert érintik.

Sterling Hughes:
"Először, a PHP/MySQL licenszelési konfliktus még nincs megoldva. Ajánlottak már egy megoldást, de egyelőre semmi sem végleges.
Igazából jelenleg a PHP minden változatával megsértjük a MySQL licenszét, amíg a MySQL azt állítja, hogy a GPL protokollszinten (TCP/IP) is továbbérvényesíttendő. Személy szerint azt gondolom, hogy ez egyáltalán nem így van, de legalábbis a MySQL definíciója szerint megsértjük a licenszüket. A 4.0-val ebben a pillanatban biztosan nem csomagolhatunk MySQL kliens kódot, hiszen nem vagyunk GPL kompatibilisek.
Na, azért még nem kell elbújdosni: ez változni fog majd, a MySQL-nek van egy elfogadható ajánlat a tarsolyában. Csak idő kérdése a megegyezés, a PHP 5 végleges megjelenése pedig még messze van. Más szavakkal a dolog megoldódik (és mindig megoldódik valahogy) a PHP 5 végleges megjelenése előtt.
... Néhány kérdés megválaszolása:
try/catch Ez nem a spagetti-kódolásról szól, mint azt Peter Moulding (vagy John (?)) javasolná. Igazából a hibakezelés- és a program logikájának különválasztásáról szól, amely olvashatóbb kódhoz vezet. A kódon belül szétszórt számos if feltétel kicserélésével a számos catch utasításra a kód legvégén világosabban látjuk a programunk szerkezetét.
Az if feltételek folyamatos használata a funkcióhívások esetén a következő hátrányokkal rendelkezik:
- nem lehet "elkapni" az E_ERROR hibákat
- összekavarja a kód logikáját
- el kell kapni minden egyes hibát a kódban. Ha nem így teszünk, akkor az csendben (vagy nem olyan csendben) működésképtelen lesz időnként.

Másodszor az "egyedi tagokról" (private members). Ez a tagokkal való interfész-szerződésről szól. Az "egyedi" (private) nem arról szól (mint azt sok ember gondolja), hogy korlátozzuk a hozzáférést a tag-változókhoz. Az a végső eredmény, de inkább arról szól a dolog, hogy programozási szempontból kikényszerítsünk egy interfész-szerződést.
A webprogramozás nagy részében ez kicsit elméleti dolog? Persze. De hihetetlenül hasznos lehet a nagy keretrendszerek, mint pl. a PEAR számára. Ha valaki kiterjedt OO módszereket használ a webprogramozásra, már vesztett.
A "tag-változók" (member variable) elérésével kapcsolatban, igen, kicsit lassabb. De ez csak azért van, mert hülyén van megvalósítva a dolog. A PHP amúgy is lassú, mint a fene, egy kis lassulás már nem számít.
...
Végül pedig ez a cikk. John [Lim] megjegyzi: "Ez a pasas sohasem csinált igazi sebességteszteket. A Perl a legtöbb dologban gyorsabb. Szerencsére a PHP legalább a szövegkezelési műveletekben eléri a Perl gyorsaságát, ami ideális leggyakoribb felhasználási módja, a honlapok kiszolgálása esetén." Tudom hogy csak piszkálódok itt, de ez egyáltalán nem igaz. A PHP meg sem közelíti a Perl sebességét egyetlen kategóriában sem, különösen nem a szövegmegfeleltetésben (string matching), ahol a Perl megfelelően használva különlegesen gyors. :)"

*: Mi a "private members" "hivatalos" magyar fordítása? Én nem találkoztam még vele magyarul, de ez feltehetőleg csakis hiányos műveltségemnek tudható be... Ha valaki ismeri, kérem küldje el az e-mail címünkre! (Ld. jobboldalt) Köszönöm!
 
1

Re: PHP-s kérdések tisztázása

Hojtsy Gábor · 2003. Júl. 28. (H), 17.47
És a PHP nem is sebességének köszönheti népszerűségét. Gyakran (nem mindig) sokkal fontosabb a kód fejlesztésének gyorsasága, mint a kész program gyorsasága.
2

Re: PHP-s kérdések tisztázása

Anonymous · 2003. Júl. 28. (H), 18.02
A Perl CGI-ként futtatva szokott lassabb lenni (nyilvánvaló okokból), mint a modulként futtatott PHP, de a Perl-t is lehet modulként futtatni, illetve más lehetőségek is rendelkezésre állnak (SpeddyCGI).