PHP Namespace vs PEAR Naming Convention

[ivanhoe]

Off Topic: ja moram priznati da u jeziku poput php-a ne vidim potrebu za tolikim OOP formalnostima, base klasama, interfejsima i sl... meni se ta Zend filozfija ne dopada, ako hoces javu, programiraj u javi, nemoj od php-a praviti javu po svaku cenu... napravi se duboko stablo nasledjivanja, funkcije pozivaju fuinkcije, koje pozivaju funkcije, itd... i onda se cude zasto im se sajt vuce cim skoci poseta... just my 2 cents

[MaxMagnus]

Originalno napisao ivanhoe

Off Topic: ja moram priznati da u jeziku poput php-a ne vidim potrebu za tolikim OOP formalnostima, base klasama, interfejsima i sl... meni se ta Zend filozfija ne dopada, ako hoces javu, programiraj u javi, nemoj od php-a praviti javu po svaku cenu... napravi se duboko stablo nasledjivanja, funkcije pozivaju fuinkcije, koje pozivaju funkcije, itd... i onda se cude zasto im se sajt vuce cim skoci poseta... just my 2 cents

ne razumem ovakav stav? MVC, Factory, Strategy... sve su to korisni patterni, koriste se u mnogim jezicima, predstavljaju best practice u razvoju aplikacija. Duboko stablo nasledjivanja. sta to znaci? 27 nivoa dubine! funkcije koje pozivaju funkcije? pa zar to nije osnova ponovne upotrebljivosti koda. zar treba ja sve da ih pozivam sam... jasno mi je ako se pishe neki CLI skript, da je glupo dizati full stack FW za neki prosto zadatak. ne gadim se ja od proceduralnog programiranja u PHPu, daleko od toga, ali razvoj FWa je isto sto i kutija alata za jednog auto mehanicara.

sto se tiche dubine stabla nasledjivanja, prizajem da sam i ja svojevremeno znao da pretaram, ali cak ni tad nisam isao nesto extremno "duboko". sad kad je nivo veci od 3-4 (ne racunajuci base name, kao npr Zend) stanem, ponovo pregledam kod i preradim stvari. naravno ovaj problem je mnogo "manji" prelaskom na namespaces...

kad se nekome sajt vuche, ne mislim da to ima samo veze sa ovim stvarima koje si ti naveo. ako neko ne zna da isprojektuje aplikaciju ili bazu, apsolutno je nebitno ovo sto si ti napisao. vidjao sam aplikacije koje za proste stvari izvrse stotine (100+) SQL upita samo da bi prikazale 100 rekorda iz baze. mislim stvarno ... pa sve preko 5 upita po "standardnoj" strani nema smisla...

[MaxMagnus]

@jablan: nisu moje klase, vec klase iz Zend FWa. u slobodno vreme pravim svoj licni FW po mom ukusu, pa sam od Zenda preuzeo par klasa (licenca dozvoljava) i preradio ih kako su meni odgovarale. Klase su pisane za php5 ali sa izlaskom 5.3 i mnogih prednosti i poboljsanja koje nudi, ja sam odlucio da u startu pocnem da koristim sve te prednosti...

tako sam radeci naisao na par klasa koje su pravile problem. neke od primera su:
Zend_Db_Adapter_Abstract
Zend_Controller_Dispatcher_Interface
Zend_Config_Writer_Array
Zend_Session_Namespace

sve ove klase koriste na kraju rezervisane reci tako da je prelazak na namespaces problem jer se dolazi do sledeceg stanja:

namespace Zend\Db\Adapter; class Abstract;
namespace Zend\Controller\Dispatcher; class Interface;
namespace Zend\Config\Writer; class Array;
namespace Zend\Session; class Namespace;

a ovo naravno ne moze... pretpostavljam da ce ZFW2 ovo takodje resiti na neki nacin, ali to je vec njihova stvar.

Jos jedna sitnica postoji, a to je da se cesto koristi ("zadnje") ime klase i za ime metoda. Primer je npr Zend_Application_Bootstrap koja ima metod bootstrap(). Prebacivanje na "class Bootstrap" dovodi do strict greske, posto su ime metoda i klase isti sto dovodi do toga da je __construct() "ponovljen" (php4 nacin)... ok, ovo je jednostavno resiti, samo sam naveo kao primer problema.

[ivanhoe]

Off Topic: @jablan: namespace je super dodatak, jedino je IMHO debilno sto su izabrali backslash. I da ne ispadne da pljujem po OOP pristupu, interfejsi su ok za velike projekte tipa Zenda, kao i cela ta OO hijerarhija, samo IMHO treba to raditi sa mozgom i prakticno, da pomaze, a ne da bude objekata radi...

@maxmagnus: a sto ne bi spojio zadnja 2 dela? Meni to deluje kao najlogicnije... Zend\Controller\Dispatcher\ a klasu nazoves Dispatcher_Interface, pa ce ti onda posle biti class Moj_dispatcher implements Dispatcher_Interface {...} sto je prilicno jasno

EDIT: @maxmagnus: izvini nisam video tvoj odgovor odmah, a i delom sam vec napisao Jablanu iznad: ne kazem naravno da je OOP los, samo da ljudi, narocito kad dodju iz drugih jezika kao java ili C++ ili sveze sa faxa imaju tendenciju da naprave sistem koji je nepotrebno komplexan (za ono sto php obicno sluzi). A sto je sistem kompleksniji to vise do izrazaja dodju propusti u arhitekturi, pa onda bude nocna mora dok prvo pohvatas kako uopste cela stvar radi, a posle gubis vreme trazeci po stablu nasledjivanja koje metode gde postoje, u milion fajlova, i na kraju umesto da bude lakse i brze za razvoj bude bas obrnuto, vecinu vremena trosis rvuci se sa manama sistema. I postoji problem sa performansama, jer je php spor u radu sa pozivima funkcija generalno, a posebno metodama koje su zakopane u parent klasama... funkcije koje pozivaju funkcije su ok, ali ako imas 10 nivoa konstruktora koji pozivaju parent konstruktore (uglavnom reda radi, samo proslede argumente), to je po meni suludo, sem ako mi daje neku vrednost u radu zauzvrat (a uglavnom ne daje, tipa svaka "medjuklasa" koja je nasledjena samo jednom je visak, a ljudi prosto obozavaju da naprave apstrakcije koje nikada nece koristiti)...

naravno to je stvar dobrog projektovanja, da se balansira ono sto je lako programeru da napise i ono sto je lako masini da izvrsi, i svi ti problemi mogu da se izbegnu, samo ljudi (vrlo) cesto to ne uspeju jer se previse oduseve kompleksnoscu svog koda... imao sam priliku i da ja parvim tu gresku, a i da radim na tudjim velikim projektima kojima je to kamen oko vrata, a inace su ih pisali vrhunski programeri...

[MaxMagnus]

Originalno napisao ivanhoe

@maxmagnus: a sto ne bi spojio zadnja 2 dela? Meni to deluje kao najlogicnije... Zend\Controller\Dispatcher\ a klasu nazoves Dispatcher_Interface, pa ce ti onda posle biti class Moj_dispatcher implements Dispatcher_Interface {...} sto je prilicno jasno

trenutno resenje koja primenjujem je slicno, samo bez "_" karaktera. DispatcherInterface. razlog je komplatibilnost sa autoloader funkcijom koji ime klase "prevodi" u putanju pa se "_" ili "\" prevode u DIRECTORY_SEPARATOR

edit: zaboravih da obrazlozim zasto mi se ovo ne svidja. ne volim mesanje velikih i malih slova u imenu klase (vec se reci razdvajaju dodatnim karakterima _ ili \) iz razloga sto postoje odredjeni (vrlo korisni, ne bih sad da ulazim u detalje) scenariji kada je potrebno generisati ime klase a onda je tesko postici da je ime ispravno. ok, to verovatno nikad nece biti neka abstraktna klasa ili interface iz sasvim ociglednog razloga (ne moze se instancirati ni jedno on to dvoje) ali moram da se ogranicim u konvenciji imenovanja, da se takve stvari ne dozvoljavaju.

[jablan]

Off Topic:

Originalno napisao MaxMagnus

...iz razloga sto postoje odredjeni (vrlo korisni, ne bih sad da ulazim u detalje) scenariji kada je potrebno generisati ime klase a onda je tesko postici da je ime ispravno...

Ovo što ti praviš već postoji i zove se Rails i radi nad jezikom kome je metaprogramiranje ko dobardan.

[MaxMagnus]

@ivanhoe:

jasno sve, razumem sta si hteo da kazes. i slazem se. pre neki dan sam negde procitao negde ovde na DPTu, da ne trazim sad tacno, bluesman je rekao da misli da ne postoji projekat na svetu koji je poceo sa projektnom dokumentacijom i na kraju ispao upravo onako kako treba, naravno neki normalno velik projekat. da, setih se sad, ona "stara" prica kako ljudi blate php da je sranje, a sama cinjenica da PHP pokrece takve velicine (a ovo je mala rec) kao sto su FB i YAHOO je dokaz sta sve taj, po njima los, PHP moze da uradi. sto rece goran, verovatno je jedini jezik kojem mozhesh da gurnesh svakakva sranja i on da to proguta i da radi sa osmehom

sad ce neko (@jablan ) da dodje i kaze kako naravno pored PHP su tu gomile drugih stvari, npr HipHop kod FBa, i da blati malo PHP...

ono sto nisam najbolje razumeo je ovo sa slabim performansama kod poziva funkcija. zar je resenje da se smanji broj funkcija koje se pozivaju... koji je magicni broj?

hajde da pogeldamo sa druge strane: kad se pishe neka funkcija? pored gomile drugih validinih razloga, jedan od njih je i kad je potrebno neku funkcionalnost koristiti na vishe mesta (konekcija na bazu, izvrsavanje upita i slicno, osnovne stvari). e sad, da li je bolje svaki put pisati kod od nule, i time odstupiti od DRY principa sve zbog neke mikrooptimizacije, ili taj kod prebaciti u funkciju i koristiti ga svaki put kad postoji potreba... naravno, obojica znamo odgovor na ovo pitanje. e sad, ako je aplikacija velika, kompleksna, imace i vishe poziva ali mislim da je to sve opradvano, jer problemi koji kasnije mogu nastati pri losem projektovanju su mnogo gori od toga sto ce se izgubiti mikro sekund po prolazu, ako se ustedi koji koji poziv funkcije...

[ivanhoe]

sve je ok, dok god ti imas jasan razlog zasto to pises bas tako. Nema smisla zrtvovati lakocu rada zbog performansi, sem naravno tamo gde za to imas smisla

Magican broj je onaj neophodan minimum da bi sve radilo i moglo da se lako koristi onako kako si ti zamislio, to je pre svega stvar licnih preferensi i zahteva projekta... ako pravis aplikaciju za 10 ljudi nebitno je, ako pravis CMS koji ce da ima peakove trafika onda je bitno... uvek mozes da resis problem i povecanjem resursa, to je isto sasvim legalan pristup, ako si siguran da mozes da skaliras vertikalno koliko ti treba u buducnosti...

a problem je kad dodje sef i pita te sto ovo tako sporo radi, a ti mozes jedino da mu kazes: zato sto ti je tako napravljen sistem u pocetku...jer ti onda obicno zapadne da smisljas kako da to ipak resis...

[ivanhoe]

^ postoji to i u drugim jezicima, ukljucujuci i php, vecina fw koristi tu foru odavno ...

[bluesman]

@jablan FTW Neuništiv si