|
PHP Namespace vs PEAR Naming Convention
Problem na koji sam naisao je sledeci. Pre 5.3 namespace-ova najcesci nacin resavanja problema sa imenovanjem klasa je bio PEAR NC, sa kojim sam se najvise susretao u Zend FWu. Primer:
Zend_Db_Table_Row ovo je kasnije vrlo jednostavno prebaciti na NS \Zend\Db\Table\Row. Problem nastaje kod rezervisanih reci, konkretno Abstract i Interface. Dosta klasa nasledjuje nesto slicno Foo_Bar_Abstract (ili implemetira Foo_Bar_Interface) ali onda nastaje problem: namespace \Foo\Bar; abstract class Abstract interface Interface sto se tice Abstract "resenje" sam nasao (hvala i dejanr na istom predlogu) koristeci Base umesto Abstract ali mi sad ostaje probem sa Interface. razmisljao sam se o FooInterface ali mi nije dovoljno "elegantno" (posto zelim da imam "jedinstveno" ime), bar za mene. Takodje i cesti predlozi po netu o koriscenju "I" (poreklom iz Hungarian notation) prefixa su mi pogresni (class Foo implements IFoo) Sta DPT community misli o ovome? Hvala :) |
Vidi odgovore na isto pitanje: http://stackoverflow.com/questions/1...ing-namespaces
|
@MaxMagnus: Nisam radio sa OOP-om u PHP, ali generalno ne razumem poentu interfejsa koji se zove Interface ili apstraktne klase koja se zove Abstract?
|
meni bi bilo logicno da ih nazoves Nesto_interface, ili jos bolje samo Nesto (a ocito je da je interfejs, jer interfejs moras da upotrebis na samo jedan tacno odredjeni nacin, ne mozes nikako da pomesas kad vidis kako je upotrebljen u kodu)
glavna mana madjarske notacije ili ovih sufixa/prefixa je sto ti presedne kad moras da kucas sva ta slova, niko ne zeli da mu ime klase ili interfejsa bude u 3 reda na ekranu, dugi nazivi usporavaju "skenirajnje" pogledom kroz kod... and it takes fun out of programmin' (bar sto se mene tice, osetim se previse korporativno :))... |
Citat:
Off Topic: ...osim ako nije u pitanju Rubi, gde postoji klasa Class :) ali to je zato što je ona u isto vreme i objekat. |
^ Nešto kao na primer StdClass ? Šteta što se u PHP-u niko nije setio toga :)
|
Ne baš. Koliko kapiram, stdClass je neka prazna klasa (ali ne i bazna klasa za sve ostale klase). BTW, šta znači ovo "std"? Mora da je nešto logično. :P
Rubijeva Class je klasa čije su ostale klase instance (npr. klasa String je instanca klase Class). |
@jablan: kao sto i sam rekao nisi radio sa OOP pa ni ne shvatam tvoj post? na moje pitanje si odgovorio pitanjem... i trazio od mene da ti je objasnim koji motiv su kreatori Zend Frameworka imali kad su klase nazivali tako. ja sam uvek ucio da se ne koriste kljucne (rezervisane) reci, pa tako nemam tabele koje se zovu select, nemam klase koje se zovu Abstract i Interface... Licno a i na poslu za Abstract klase koristimo Base, posto to ima smisla. Nemam "resenje" za interfejse.
Meni se licno ne svidja prefixovanje sa I, jer se slabo "vidi"... Moze li neko da podeli svoja iskustva sa nama, kako ostali nazivaju svoje klase, i koliko ljudi koristi namespaces u PHPu? |
Citat:
|
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 |
Citat:
Citat:
@ivanhoe: Ne znam da li tu ubrajaš i namespace-ove, ali oni itekako imaju smisla. Doduše taj smisao se gubi ako se postojeće funkcije ostave u globalnom NS-u. |
@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. |
Citat:
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 :D... pa sve preko 5 upita po "standardnoj" strani nema smisla... |
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... |
Citat:
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. |
@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... |
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... |
Off Topic: Citat:
|
^ postoji to i u drugim jezicima, ukljucujuci i php, vecina fw koristi tu foru odavno ...
|
@jablan FTW :) Neuništiv si :)
|
A ako u narednih 5 minuta pocnete da koristite Ruby/Rails, dobicete ovaj neverovatni otvarac za konzerve, POTPUNO BESPLATNO!
|
ja sam počeo! a koji to otvarač za konzerve, ne vidi se link :D
edit: i da li mora odmah da se počne sa OOP ili može i proceduralno (za početak dok se ne snađem) ? |
^ Za pocetak ... u ruby-ju su sve klase i objekti :)
|
E, hajde stvarno ... GTFO ... vidite naslov teme, ko vas pita za ruby i smalltalk :) Napravite temu "Ruby" pa se izljubite i načestitajte nove godine, nemam ništa protiv :)
|
^ party pooper ;)
|
Ja sam čuo da sa rubijem može ceo web da se programira? :D
|
http://www.youtube.com/watch?v=iDbyYGrswtg
Off Topic: Sorry, Ruby me malo razmazio, zaboravio sam komplikovanu ali nadasve logičnu sintaksu za embedovanje YT klipova... |
Hm, sada mi je sve mnogo jasnije ... dakle Ruby obožavaju ljudi kojima je ovo smešno i zabavno :) Zato je valja taj Ruby i toliko exciting :)
|
| Vreme je GMT +2. Trenutno vreme je 10:53. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.