PHP 5.3.0

PHP

Megjelent a PHP programozási nyelv következő nagyobb kiadása, amely az 5.3.0 verziószámot viseli. Az újdonságok között megtalálható többek közt a névterek használata, korlátozott ugrási lehetőség, névtelen függvények használata, és néhány új kiterjesztés. További információ a hivatalos bejelentésben.

( mhmxs v | 2009. 07. 01., sze – 13:48 )

Optional garbage collection for cyclic references, ennek mi értelme is van? vagy csak nekem nem jutott még eszembe, hogy ilyesmit használjak?

Mit miért? Nulla OOP. Ez nekem több, mint elég. Meg pl. myisam motor. Meg főoldal generálás ~100 db select. A gányolás magas foka.
Funkcionalitásban jó, rengeteg modul van hozzá, csak ne kelljen hozzáfejleszteni. Jaj, legalább ilyenkor ne gondolnék rá!

Igen. Sajnos olvastam. Egységbe zárásról, polimorfizmusról, meg mintákról hadovál, holott semmi köze nincs ezekhez. Mondaná azt, hogy régi rendszer, sajnos amikor készült még nem voltak ilyenek, újraírni meg sok idő lenne. Ehelyett összehord egy nagy rakat baromságot.

http://toys.lerdorf.com/archives/38-The-no-framework-PHP-MVC-framework…

"...the idea that because something is procedural it is automatically spaghetti while OOP is not is pretty funny..."

"... I have nothing against OOP when used correctly, but I see a lot of things approaching HTML classes where you end up doing $html->br() just to spit out a break tag. That makes absolutely no sense to me."

Az idézetekkel egyetértek. Viszont:
Kb. 2-3 óra alatt írtam egy wrapper osztálykönyvtárat, aminek segítségével össze tudok rakni egy formot, meg ki tudom váltani a menu_hook()-ot. Nem kell fejben tartanom az asszociatív tömbök kulcsait, hol mi lehet, stb. Összerakom a formot kb. mint a ZF-ben (persze ez jóval kevesebbet tud), és nyomok egy toArray()-t, amit már megesz a drupal. Nem kell túrni a form apit, autocomplete a barátom.
Erre miért nincs igény? Minimális időráfordítással nagyságrenddel lecsökkenthető a későbbi fejlesztési idő. Ez az OOP előnye. Sajnálom, hogy 2009-ben erről kell még mindig beszélni.

Ez azért van mert gondolkodsz. Mások meg nem. Inkább megindokolják, hogy miért esznek szart, minthogy a szart lecserélnék rántott husira. Egyébként nekem is ez a gondom, mint neked. Csak a szarlapátolás van ahelyett, hogy valami értelmeset és használhatót csinálnának, csinálnánk. Na és persze ilyenkor jön az ugatás, hogy a java mennyire szar, meg satöbbi... Csak olyan támogatást képes adni a fejlesztő környezet, hogy nekem csak a logikára kell figyelnem, nem pedig arra, hogy melyik tömb melyik dimenziójában...

Igen, 2009-ben még ez a téma... de szerencse, hogy vannak olyan területek, ahol ezen már régen túlléptek.

-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --

Azért tegyük hozzá, hogy közel sem biztos, hogy mindenhol az általatok annyira favorizált OOP a megoldás, előtte is írtak szép, hatékony és átlátható programokat. Én nem kedvelem különösebben az OOP-t, és szerintem a Drupal pont a szükséges és elégséges szintig támogatja azt. Különösen, hogy az alapja egy olyan programozási nyelv, amely azért nem az erős OOP megvalósításáról híres.
Szóval amikor azt mondod, hogy szar vagy rántotthús, akkor azért tedd hozzá: a te szád íze szerint.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Azt azért nem mondtam, hogy mindenhol favorizálom az OOP -t. Van ahova én csak odatoszok valamit, hogy menjen. Ha van időm, akkor igenis meg fogom szépen csinálni, mert igenis lehet szépen csinálni.

-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --

Mondjuk megnéznék egy kernelt, vagy egy alacsony szintű lib-et OOP-ben. És persze ez nem arról szól, hogy az OOP szar, vagy az OOP a király, hanem hogy mindennek megvan a maga helye. Szerintem.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

kernelek azert nem irodnak oopben mert az oo joval lassabb (plane kernel szinten). Egyebkent egyesek megprobaltak abban irni (pl eredetileg windoz kernelt is, aztan rajottek hogy rohadt lassu es eldobtak az otletet ha jol tudom... marmint meg a kezdetekkor). De ilyeneknel nem arrol van szo hogy ki mit szeret vagy melyik szebb, egyszeruen egy kernelnel nagyon szamit a sebesseg...

Mert az objektumok több helyet foglalnak a memóriában, főleg ha sok van belőlük. Arról nem is beszélve, hogy olykor csak az egész objektum egy kicsi szeletére van szükség az aktuális műveletekhez, de ettől az egész bent csücsül a memóriában. Nem véletlen találták ki javaban az eager és lazy objektumfeltöltési modellt.

Mérj, és majd meglátod. Egyszerűen, mivel a processzorok nem objektumorientáltak, és az optimizerek és fordítók meg nem mindenhatóak. Sok előnye van az oo-nak, de ahol gyorsnak kell lenni, oda teljesítményre optimalizált kódot kell rakni, az meg oo szemlélettel nem igazán megy.

Vagy az nem tud magyarul aki írta azt, amire reagálsz, vagy te. ;) Vagy csak szimplán kontextus nélkül értelmezed a mondanivalóját, hogy még a véletlen se legyen melette... ;)

Lehet, hogy csak én vagyok olyan hülye, hogy fontos, hogy milyen támogatást képes adni a fejlesztői környezet. Tök mindegy milyen nyelvről van szó. Gondolom a java fejlesztők felismerték ezt, mert kiscsillió package és osztálymetódust fejben tárolni vagy fejlesztés közben a doksit kattintatni kissé fárasztó és nem hatékony és ezért kezdtek el fejlődni a javahoz elérhető környezetek ilyen irányba. Az egy más dolog, hogy a php-s körökben még mindig menő notepadban programozni.

PHP esetében a NetBeans például nagyon szépen tud a kezed alá dolgozni. És ami még tetszik benne, hogy ösztönöz arra, hogy a kódodat dokumentáld, mert abból veszi egy - két információt.

De persze az is lehet, hogy én gondolkodom hülyén már megint... ;)

-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --

Az OOP léte vagy nem léte önmagában semmit sem jelent (csak azok szeretnek rá felvágni, akik nem tudnak programozni). PHP-ban nem sok értelme van, mert a PHP-nek semmi köze az OOP-hez (van class és interface, de aki írt egy sor teszem azt Smalltalk kódot, az tudja, hogy nem csak a nyelvi elemeken mérik az OOP-t). Van SPL, de az még gyerekcipőben van és nem elterjedt (azon kívül csak egy rátaknyolt réteg a teljesen elcseszett PHP API-ra, szarra meg nem lehet várat építeni).

A sok query egy mellékhatása annak, hogy szét lehet hackelni. Ez valamelyes csökkenni fog Drupal 7-re, de sajnos itt megint a PHP hiányosságai jönnek be. Ha lenne egy réteg, ami folyamatosan tudna egyfajta démonként futni (ahogyan az kultúráltabb rendszereknél meg is történik, lásd java, .net stb), akkor csak elsőre lenne ennyi query, majd a cache és az ORM megfogná ezeket. Most csak annyiban gyors ez, hogy egyrészt egyszerű lekérések, amiket a mysql nagyon jól tud cache-elni, másrészt nagyjából ugyanazokat kéri le, így azok a mysql query cache-ből lesznek kiszolgálva, ami viszonylag gyors (csak nagy legyen a sávszél a Drupalt futtató szerver és a mysql szerver közt).

Gányolás hm. Megnézném, hogy az általad legjobban favorizált oop rendszerben mikor raknál össze olyan szép rendszert, mint a Drupal. Pl ilyenek, hogy szinte bármilyen változtatást meg lehessen csinálni a tartalmon egy pár fájl bemásolásával (anélkül, hogy a core-hoz hozzányúlnál). Vagy mikor csinálnál te olyan flexibilis API-kat (sokszor lepődünk meg a cégnél a kollégákkal, hogy egy-egy API-ban milyen lehetőségek vannak).

Itt most nem arról van szó, hogy én milyen API-t tudnék írni. Igen, kódoltam smalltalkban, meg még vagy 15-20 nyelven, és valóban vannak jobb megoldások a PHP-nél, de megint csak nem erről volt szó. Akinek meg az OOP előnyeiről kell beszélni, az járjon még egy kicsit iskolába.

"Gányolás hm. Megnézném, hogy az általad legjobban favorizált oop rendszerben mikor raknál össze olyan szép rendszert, mint a Drupal. Pl ilyenek, hogy szinte bármilyen változtatást meg lehessen csinálni a tartalmon egy pár fájl bemásolásával (anélkül, hogy a core-hoz hozzányúlnál). Vagy mikor csinálnál te olyan flexibilis API-kat (sokszor lepődünk meg a cégnél a kollégákkal, hogy egy-egy API-ban milyen lehetőségek vannak)."

Hmmm... azért egy keretrendszer több éves fejlesztését és milliós nagyságrendűnek tekinthető fejlesztési óráját, illetve tapasztalatát elvárni egy szem fejlesztőtől kissé túlzás, nem gondolod?

-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --

Valahol értem a problémádat, csak arra nem gondolsz, hogy mi szükség vajon memóriában gyorstárazásra egy olyan portálnál, amelynél napi 100-1000 lekérés van. És ez több mint az átlag.

Másfelől ha fürtözve vannak a gépek, márpedig fürtözve vannak, akkor vagy ragadós munkamenet, vagy távoli objektumelérés kellene hozzá.

mi a sajat rendszerunkon barmilyen (nem design) modositast megejtunk adatbazis pocogtetessel:)

egyebek: a sok lekerdezes egyfelol nem jo, masfelol meg --ha egyszeru lekerdezesekrol van szo-- gyorsabb, mintha ezer JOIN-nal megpakolt adatbazis lekeresek lennenek.

egyebkent nyilvan arrol van szo, hogy nem lehet akarhanyszor elorol irni egy rendszert, a modositasoknak megvannak az elonyei es hatranyai. a masik indok az "agyuval verebre"-effektus, ami miatt nagyon sok projekt a mai napig ugy indul php-ban, hogy nem OOP (aztan kesobb mar keso...)

Ha normális MVC rendszert akarok, akkor django, ha gyorsan kell valamit mutatni, akkor rails, ha már hanyagolom a Drupalt.

A Drupal sem rossz, órási előnye, hogy az utolsó szögig szét lehet haxxolni (ha a megrendelő engedi, akkor majd a kollégákkal felrakunk pár érdekes modult), de közben egyben marad a rendszer. Sajnos a PHP elég szar nyelv, mert nem nagyon támogatja a domain specifikus nyelvek "létrehozását", így pár API kényelmetlen (pl.: form api, hook_menu) szintaktikailag.

Meg lassan a spájzban van a Drupal 7, ami nagyon nagy változás lesz (talán az eddigi legnagyobb ugrás a Drupal történetében), nézd meg majd utána a Drupalt :)

( balazs10 | 2009. 07. 01., sze – 14:33 )

ha jól látom már a Windows Server támogatást is tovább finomították és erre dedikált oldalt is létrehoztak...

előbb utóbb betör a php a windows platformra is :)

B10

Nem, mint ahogy nem kellene alternatív syntax a control structurakra sem.
Nem baj, hogy létezik, bár az igazat megvallva sokkal előbb kellett volna és kb most kellene deprecated -nek lennie...:P

"-Pedig vegetariánus vagyok; csak növényevő állatokat fogyasztok!"
azenoldalamponthu

Nekem a python fejlesztési folyamata sokkal jobban tetszik. Nem az van, hogy beledobálnak mindent, aztán majdcsak jó lesz valamire/valakinek, hanem alaposan megrágják, hogy kell -e. Pl. nem került be a 'labeled break' sem, ami egy kissé fájó, de ha belegondolunk, valahol igazuk volt, mert az is egy goto, épp csak le van korlátozva a használata. (És tapasztalatom szerint amúgy is ritkán kell, ha pedig többdimenziós adaton kell dolgozni, arra ott a zip(). )

Gyanyítom, hogy páran igényelték.
Másként meg ez valamilyen hasonlóságot hivatott inkább teremteni más nyelvek szintaxisával/használtával.
Mondjuk nem kizárt, hogy fogom használni, ha már van...
De ismétlem: ezzel k...ra elkéstek.
C64 basic idején találkoztam vele először...

"-Pedig vegetariánus vagyok; csak növényevő állatokat fogyasztok!"
azenoldalamponthu

( snq- | 2009. 07. 01., sze – 15:02 )

hihetetlen milyen szakadék van nyelvek/keretrendszerek között

( Tyra3l | 2009. 07. 03., p – 03:22 )

minden lapletoltesnel futasidoben felhuzni a rengeteg osztalydefiniciot, feloldani a leszarmaztatasokat, interface implementalast, stb.
opcode cache-sel csak a parseolasi idot tudod megsporolni.
szoval szvsz esszel kell banni a nem alkalmazas-szerver jellegu vasakon az oop-vel.
felteve ha alacsony valaszidore kell skalazni.

szerk: ezt ide akartam irni.

Tyrael

( nikin v | 2011. 08. 29., h – 10:28 )

Részemről nem rajongok az OOP-ért PHP-ben. Meg úgy álltalában sem. Except JAVA persze.
Ha valamit webre írok ott a válaszidő és a memóriahasználat az atyaúristen. No meg természetesen a fejlesztési idő. Én a procedurális PHP-ban találtam meg a számomra legjobb alternatívát. Ha nem játszana a fejlesztési idő, akkor valószínűleg C-ben fejlesztenék.
Tudom, hogy OOP, MVC meg Adatbázisnormalizálás, meg absztrakció meg tudomisén mi a kín még. És én próbáltan ezeknek megfelelően is kódolni már. És valószínűleg én vagyok a béna, hogy közel 10x lassabb lett úgy.
Igyekszem jól olvasható, jól karbantartható, kommentben gazdag, értelmes-változóneves "gányt" írni addig is.

### ()__))____________)~~~ # "Ha én veletek, ki ellenetek?" # Samsung N210 //Arch//fb//