Mint PHP fejlesztő, használsz PDO-t vagy SPL-t?

Programozás

Mindkettőt használom
2% (15 szavazat)
Csak PDO-t
7% (40 szavazat)
Csak SPL-t
1% (9 szavazat)
Nem használom egyiket sem
19% (114 szavazat)
Nem vagyok PHP fejlesztő
70% (425 szavazat)
Összes szavazat: 603

( sj | 2010. 06. 06., v – 22:14 )

sqlite3-hoz hasznalok PDO-t, mysql-hez viszont nem

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

( crystal88 | 2010. 06. 06., v – 22:45 )

hát ha az ArrayObjectből származtatás SPL használatnak számít akkor igen.

----------------------
nem jut eszembe semmi vicces :(

( pcdevil | 2010. 06. 06., v – 22:49 )

PDO-t ismertem, tetszett, bár élesben még nem használtam, SPL-t pedig most ismertem meg:)

"Nyugi! Minden a legnagyobb rendben csúszik ki a kezeim közül..." - Douglas Adams
"I can't win, but I can fight! And I make your life miserable."

( arpi_esp v | 2010. 06. 06., v – 23:23 )

Csak az eredmeny erdekel :)

A'rpi

( Protezis | 2010. 06. 06., v – 23:26 )

Elég szomorú a jelenlegi állás. Bár ez a Drupal és a hozzá hasonló fejlettségű (nem feature list, hanem kódminőség, -fejlettség) CMS-ek uralta piacon talán nem is annyira meglepő. Nem trollkodni akarok, de ami tény, az tény. Jómagam mindkettőt aktívan használom, így már ketten vagyunk. :(

Tudom, hogy azt használ, és tudom, hogy már régóta késik a kiadása. Bár pl. a hook rendszerét nem néztem meg a hetesnek, gondolom, hogy nem írták át OOP-re. Úgyhogy nagy áttörést nem várok az új verziótól sem, max annyit, hogy végre frissíthetek 5.3-as PHP-re, mert sajnos 1-2 Drupal projekt miatt kénytelen vagyok 5.2-őt használni a céges gépemen. Szóval amit leírtam, szerintem tény, lehet szépíteni a dolgot, de valószínűleg nem fog hirtelen a Drupal közösség SPL interfészekkel és osztályokkal dolgozni. És igen, leírnám mindezt a drupal.org-on is, ha minimális értelmét látnám és ha nem írták volna le már mások is.

Valószínűleg, hogy akik SPL-t és/vagy PDO-t használnak, azok valamilyen MVC keretrendszert használnak, és ezek a PHP programozók egyelőre kisebbségben vannak.

Volt róla szó, de felesleges lenne a hook rendszert a mostani állapotában átírni, mert csak komplikálná a dolgot.

Viszont a hook-ok át lettek szervezve, meghalt az utolsó mammut hook (hook_nodeapi), és ahogy tudom nincs több $op paraméter sem (vagy csak minimális).

A Drupal fejlesztők többségének az az álláspontja, hogy egy adott technológiát ott használnak, ahol előnyt jelent. Nem fogják átírni a core-t csak azért, hogy minden include fájlban legyen 1-2 jól hangzó osztálynév/interfész az extends/implements kulcsszó után :) Azonban az is igaz, hogy az OOP lehetőségek még messze nincsenek kiaknázva. Ehhez egyrészt sokkal több idő kellett volna, másrészt pedig nem árt a tapasztalat és a visszajelzés a közösségtől.

Komoly agyalás folyik a Drupal fejlesztési irányáról, főként a Drupal 8-at érintve (szeretnék, ha PHP framework-ként is megállná a helyét). Az egyik fő cél egy nagymértékű kódtisztítás és az egybeolvadó alrendszerek teljes szétválasztása (ez jelenleg probléma, mert minden össze-vissza hivatkozik egymásra és sok olyan függvény van, ami több alrendszerhez is tartozik egyszerre). Gondolom majd itt fognak egyes alrendszereket (vagy azok részeit) objektumorientáltra átírni.

Főként nem a modulokkal van a gond, hanem azzal, hogy maga a keretrendszer része a core-nak (includes/) tele van hard depencency-kkel. Pl nem tudsz olyat csinálni, hogy csak a theme és a db layert használod fel. Ez fog a jövőben változni. Emiatt nagyban javul a tesztelhetősége is (nem az egészet kell tesztelni, hanem csak az adott alrendszert, illetve az alrendszerek integrálódását).

Nem a nyelvi elemektől lesz jobb a végeredmény és egyszerű a rendszer. Jó példa erre a java és a hozzá kapcsolódó "bürokratikus" megoldások. A weben ezek nem járhatóak, nagyon rövid a egy technológia életciklusa és arra kellenek speciális megoldások. A sokmillió absztrakciós réteg előnye eloszlik a teljesítmény és a rugalmasság tekintetében, a tanulási görbéről nem beszélve. Hiába a jól átgondolt, mindenféle szabványnak megfelelő iPlanet, ha nem lehet költséghatékonyan hosztolni és az első űrlap kiíratásához komoly mennyiségű szakirodalmat kell átolvasni? Lehet becsmérelni a szándékosan egyszerű felépítésű rendszereket, de mivel ez is egy rendszer, ugyanazt el tudod végezni vele, mint bármi mással. Mindezt igen széles felhasználási tartományban, a legnépszerűbb webes programnyelven, akár kevés fejlesztői tapasztalattal. Nekem ezek voltak a fő szempontok, amikor a Drupal mellett döntöttem.

Konkrétan milyen hátrányát érzed annak, hogy nem teljesen OOP alapú a Drupal?

Csak egy másikhoz képest lehet érezni a hátrányát, pl amikor Concrete5-re kell fejleszteni, utána soha többet nem akarok Drupalt használni, mert egy szenvedés ahhoz képest.

Persze a megrendelő legtöbbször Drupalt kér, sőt én is sokszor javaslom, de azért óriási minőségi különbségek vannak. Druppal azoknak jó, akik megrendelőként bele akarnak gányolni a rendszerbe vagy az unoka ért hozzá, mert már telepített egyet WAMP szerverre.

Persze vannak nagyon komoly oldalak is Drupal alapokon.

--
http://sandor.czettner.hu

"Még milyen szerencse, hogy erről sem a Fehér Ház, sem a nagyobb zenei kiadók, sem hatalmas hírportálok nem tudnak *huh*"

Milyen szerencse, hogy kit erdekel. Ez a legidiotabb es minden szakmai ervelest nelkulozo marketing bullshitra hajazo fassag, amit hangoztatni lehet, hogy a masik is ezt hasznalja.

----------------
Lvl86 Troll

valamilyen szinten egyetertek en sem esek hasra attol, hogy valami *csak* attol jo, mert sokan hasznaljak (wordpress -szerintem es ugy tudom, hogy sokan masok szerint is- egy nagy rakas kaki minden szakmai szempontbol, viszont mukodik, es emiatt egy csomo ember ezt hasznalja, ami miatt egy csomo ember fejleszt ra...), de ahogy zoner is megjegyezte a drupal nem ezek koze tartozik, nagyon komoly cegek is hasznaljak, es nem veletlenul.
nekem drupal kapcsan az a velemenyem, hogy sokkal kevesbe nyalja ki a segged, mint mondjuk egy joomla, ha csak kattingatni tudsz benne, viszont ha fejleszteni kell hozza, akkor ezerszer halasabb, mint a joomla.

ps: c5-ot meg meg kell sasoljam, mert mostanaban egyre tobbszor hallok rola, es kivetel nelkul pozitiv dolgokat.

Tyrael

Szerinted Obamát mennyire érdekli, hogy 100 sql query fut le indulásnál, hogy minden node-ot külön kér le a rendszer egy alap listázásnál, hogy valószínűleg myisam motort használnak így nincsenek külső kulcsok, hogy raklapnyi notice-t dobál (jó esetben csak azt)...
Nem érdekli. A lényeg, hogy működik, és hogy jól néz ki. Akinek ez elég, annak elég a Drupal. Gyorsan (már ha olyan kell, amit már megírtak), olcsón lehet fejleszteni benne. Hogy mennyire jó, az már az adott feladattól függ.

És valaki említette, hogy OOP esetén túrni kell az API-t. Összehasonlítva ezt a Drupallal, óriási baromság. A Drupalnal nyálazni kell az API-t, hogy az adott hook 83. paraméterében vár egy tömböt, és abban melyik kulccsal kell megadni a kérdéses értéket. Míg OOP-nál nyomni kell a Ctrl+Space-t. Ez nyilván túlzás, de sokkal kevesebbet kell API-t túrni egy normális OOP rendszer esetén.

Nem hinném, hogy ahol egy kicsit is értenek hozzá, myisam motor maradna. A notice-ok core-ban nincsenek, contribok esetén pedig személy szerint rengeteg patchet küldtem be, hogy javuljon a helyzet.

Az API valóban nem a legjobb, egy régebbi világ szemléletét hordozza magán. Ezt tudja a közösség, és rengeteg kíváló szakember dolgozik azon, hogy ez változzon (kedvcsinálónak nézd meg, hogy milyen sok kódtisztítás történt Drupal 6 és 7 közt). Ez nyílván nem megy két hét alatt egy ekkora méretű projektnél, főleg, hogy nem csak ez az egy szempont lebeg a fejlesztők előtt, amikor fejlesztik a core-t. Lehet, hogy nem a legmodernebb API-val rendelkezünk, de van RDFa támogatásunk, amivel tovább növeljük az előnyünket SEO tekintetben. Majdnem mindenre van modul.

Amúgy milyen IDE-d van, hogy a definiált függvényeket nem tudja indexelni? Pont az OOP-vel van baj, mert a PHP csak "stringly typed", és nagyon sok helyen nem lehet egyértelműen következtetni, hogy mi a típusa éppen a változónak.

Zend Studio, Netbeans. Polimorfizmus esetén nyilván nem tudja megmondani az IDE a konkrét osztály egyedi, illetve felüldefiniált metódusait (type cast ugye nem működik osztálynevekkel, ha működne, akko azt is tudná), de még mindig többet elárul, mint a "@return array", meg "@param array". Igen, az IDE átnyálazza mind a hatszáz-ezer Drupal függvényt, és felkínálja nekem mindet, amivel kb. kitörölhetem, plusz az előbbi említett paraméterek és visszatérési értékek esetekben szintén kitörölhetem, mehetek a drupal.org-ra, vagy nézhetem a Drupal core-t. Ami ennél még nagyszerűbb, a func_get_args gyakori használata. Na azzal tényleg semmit nem tud kezdeni az IDE.

Jobb modulokban (igen, itt sajnos én is ludas vagyok :( ) a modul feletti doc-ban benne van a paraméterek részletes leírása, amit a netbeans meg tud jeleníteni. Ott is el lehet olvasni. Tény, hogy ez sem megoldás sok esetben. Ez azonban nem csak Drupal hiba, a PHP tervezésénél (gondolva az olyan "formabontó" megoldásokra, mint pl a func_get_args() vagy extract()) nagyon nem gondoltak arra, hogy megkönnyítsék egy forráskód elemző dolgát.

1, a feher haz valszeg kap akkora latogatast, hogyha nem lenne jol lefejlesztve/bekonfiguralva az a drupal telepites, azonnal fejreallni, ergo nem fut le lapletoltesenkent 100 query, valamint a listazasoknal sem egyesevel vannak lequery-zve a rekordok(ez szerintem amugy sincs igy a views/views2 modulban, vagy a fooldali listazasrol beszelunk?).
2, mysql engine-rol nem hiszem hogy lenne publikus info, a drupal altalaban alapbol mindenhova myisam-ot hasznal, szoval siman elkepzelheto, de egyreszt ugye a myisam mostly-read szituacioban fix sorhosszusag eseten meglepoen furge tud lenni, masreszt valoszinuleg az adatok konzisztenciaja egy ilyen oldalnal nem feltetlenul top prioritas (kb. az egesz iparag kezd elmozdulni az ACID-tol BASE fele).
3, nem hiszem hogy a feher haz fejlesztese korul a penz lett volna a legmarginalisabb kerdes.
4, ha ott valami megall/felborul, akkor azert valaki seggberugnak (azert nem Magyarorszagrol beszelunk, ahol ez mindennapos), ergo a felelos szakember nem valasztotta volna ezt az eszkozt, ha nem merne rabizni a segget.
5, ahogy irtam, nekem pont az volt inkabb az erzesem, hogy kattingatni testreszabni nem annyira kenyelmes, mint a tobbi konkurens, de fejleszteni kenyelmesebb benne, atgondoltabbnak tunik a rendszer es a dokumentacio is jobb.
6, fejlesztokent nekem a tanulasi gorbeje magasabbnak tunt az elejen, mint a tobbi rendszere (elsore szokatlan a spagettikodhoz szokott szemnek az esemenyvezereltseg. plane weben.)

Tyrael

Nem azt akartam mondani, hogy a fehér ház oldala szar és bugos, hanem azt, hogy egy egyszerű oldal, a bonyolultsága össze se hasonlítható pl. egy webshoppal. A fehér háznak tökéletesen megfelel a Drupal.

Az eseményekkel nincs semmi bajom, a Drupal megvalósítással van és szerintem a Drupal eléggé spagetti kód, legalábbis OOP után nagyon az.

Szerintem a Drupal kódja nagyon messze áll a spagetti kódtól. Nem szeretem azt az elitista hozzáállást, hogy csak OOP kód lehet szép.

Ennyi erővel jöhetnék azzal, hogy jobb helyeken az OOP az message passing, és a C++-vonal rosszul csinálja. Azt az ötletet, hogy egy objektum lényegében egy struktúra, amin operációk vannak definiálva, egyedül a Go-ban láttam szépen megoldva.

Vagy arról is lehetne szó, hogy igazán szép kód az a funckcionális, ami ráadásul nagyon jól verifikálható, tesztelhető és automatikusan optimalizálható, ami fontos a mai szoftvereknél.

Nem azt akartam mondani, hogy a fehér ház oldala szar és bugos, hanem azt, hogy egy egyszerű oldal, a bonyolultsága össze se hasonlítható pl. egy webshoppal.

Én erre nem mernék mérget venni.
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Egyébként én szeretem és használom a Drupalt, csak azért ismerek olyat, amire kellemesebb fejleszteni. De lehet, hogy ez is szubjektív, nekem az MVC és még inkább a HMVC sokkal kézenfekvőbb és az a fura, amikor egy php fájlban van SQL query, üzleti modell meg html kód. Ezeket Drupalon is igyekszem szétszedni, de sokszor nem éri meg, pl theme_ kezdetű funkciók miatt és azt is látom, hogy nagyon sok modul karbantartója is törekszik arra, hogy összeszedett kódot írjon, de van nagyon sok hajmeresztő megoldás is.

--
http://sandor.czettner.hu

( Nyosigomboc v | 2010. 06. 07., h – 00:06 )

Bar jelenleg csak hazi projectjeim futnak PHP-ban, az "egyiket sem"-re szavaztam.
Egyelore nem kellett. DB-re irtam egy nagyon kicsi, par fv-bol allo wrappert, ami MySQL-t, meg Postgres-t tud hasznalni, kizar par alap hibat (pl. SQL injectiont), ha kerem, lemeri az egyes parancsok futasidejet, ha tobbszor hivok meg valamit, magatol parameteres SQL parancsot csinal (vagy ezt hogy hivjak magyarul?), es teljesen meg vagyok vele elegedve.
Eddig nem talalkoztam olyan feladattal, amihez mindenkeppen SPL kellett volna. Bar ez lehet, hogy nem feltetlenul feladatfuggo, mindenesetre nem merult fel, hogy hasznaljam.

--
What's the difference between the Israeli navy and Somali pirates?
If you negotiate with Somali pirates,you can prevent them from murdering their victims. - sickipedia

( kikke | 2010. 06. 07., h – 09:04 )

PDO-hoz hasonló szintaxisú, saját adatbázis absztraktort használunk.

( radix | 2010. 06. 07., h – 09:07 )

Egyiket sem, mert nagyban rontja a php skálázhatóságát és teljesítményét.

nagyon egyszerű: a PHP interpretált nyelv. Minél bonyolultabb egy adott osztály, annál több php-t kell hogy beolvasson és értelmezzen az interpreter.
Az OOP szemléletmód PHP alatt ezért nem célravezető olyan feladatra, ahol performance-re lehet szükség.

Minden mindig egyszerre bent van a memóriában: user objektum, termék objektum, kosár objektum, cikk objektum.... Ahelyett, hogy csak az ID-juk lenne bent egy tömbben.
Megszokás kérdése, oké.

Nemrégiben volt egy PHP-s állásmegbeszélésem, ahol a Fejlesztési vezető Úr vizsgáztatott ezekből a három betűs szavakból, hogy mennyire ismerem őket, mire használnám, stb stb. PHP alatt kivételkezelés? OMG? :)) A vicc, hogy elvileg hír-portálmotort fejlesztenek, viszont ha ránézel arra a weboldalra, amit az a komoly "motor" kiszolgál, akkor azt mondanád, hogy 3 nap alatt összekattingatod joomlában.
A fejlesztési vezető egyértelműen javaból tanult át. Én PHP-san tudok php-t programozni, ő meg Jávásan.

Na, egy a lényeg: a PHP az nem Java vagy C++, kezeljük a helyén: ne írjunk 10 ezer soros programot benne, mert lassú lesz. Nem a futtatás, hanem a program értelmezése. (tudom, erre is már létezik megoldás a Zend háza táján, meg a facebookéknál is úgy volt hogy publikálnak valami nyílt forráskódú fordítót, azóta is pendingel a projekt)

Nem véletlenül interjúztatott az az ember, és nem véletlenül nem kaptad meg az állást. Szerintem nézz kicsit utána a dolgoknak, mielőtt egymagad messzemenő következtetéseket vonsz le ismeretlen dolgokról. Ez csak jó tanács, és nem kell megfogadnod. A hozzád hasonlók miatt mindig kicsit megnyugszok: talán soha nem leszek munkanélküli :)

A túloldalon ülő ember talán az OOP szemléletében tudott többet, mint én. Ő Jávát tanult az egyetemen, én pedig C/C++-t. Majd ezzel kezdtünk mindketten php-t programozni.
A túloldalon interjúztató ember majdnem lefordult a székről, mikor a fizetésigényről volt szó: gondolom ő egy nagyságrenddel kevesebbet keres, mint amennyi az én igényem volt.
A jó php programozó mércéje pedig nem az OOP, hanem hogy milyen gyorsan és ügyesen dolgozik, mennyire átlátható a kódja, tudja-e, érti-e hogy mit csinál.

kis olvasnivaló:

http://devzone.zend.com/article/1236#Heading4

Amúgymeg hitvallás kérdése az egész. Nem hiszem hogy 1-2 hétnél több időt venne igénybe rászokni az OOP kódolásra. Viszont leszokni róla már nehezebb:)

Az interpretacio teljesitmenyigenyerol szolva, nagyon keves olyan webhoster van, aki nem hasznal valamilyen precompilation megoldast, peldaul eAccelerator-t vagy APC-t. Persze, ehhez kell valaki, aki nem csak programozni tud, hanem hallott mar ezekrol a technologiakrol. Ezt nem sertesnek, tenykozlesnek szantam, mielott felreertened.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

"Nem hiszem hogy 1-2 hétnél több időt venne igénybe rászokni az OOP kódolásra."

Hát. őőő..... inkább 1-2 év akar az lenni.
Azért az OOP programozás nem annyiból áll, hogy mindent class-ba teszel, és az adattagokhoz getter/setter metódusokat írsz, hanem egy teljesen más megközelítés.
Olvass utána oop design patterns -eknek.

Ne ezt hivjak kokemenyen mellebeszelesnek. Mindenre valaszoltal csak arra nem amit kerdeztem. Vagy esetleg nem vagy tisztaban a skalazhatosag fogalmaval?
Bar hozzateszem hogy amit leirtal se ertek egyet.
Tipikus bullshit szoveg imho.

------------------
http://www.youtube.com/watch?v=Sf8cM7f6P2I

Nyehe, erre egyszeruen mar nem tudok erdemben reagalni.
Nem egy nagy terheleso oldal fejleszteseben reszt vettem mar. Csinaltam mint proceduralis mint OOP szemleletben. Jelenleg is egy igen nagy oldalt irok ujra OOP szemlelettel, es egy pillanatra sem rettegtem tole hogy az OOP metodika lesz az egesz mogott a szuk keresztmettszet.
Az az igazsag hogy lesut a beszededrol hogy erdemi tapasztalat nelkul hanysz ossze itt tucskot bogarat.
Vitat itt befejeztem. Nem akarom megvaltani a vilagot, teged meg plane nem kivanlak kirangatni a sotetsegbol ha ott neked jo.

------------------
http://www.youtube.com/watch?v=Sf8cM7f6P2I

Minél bonyolultabb egy adott osztály, annál több php-t kell hogy beolvasson és értelmezzen az interpreter.

ugye tudod hogy mind az spl, mind a pdo C-ben irt php extension, ezert ezeknek a hasznalatatol nem lesz tobb php osztalyod?
sot, altalaban a pdo altal biztositott eszkozok (parameter binding pl.) tipikusan olyan dolgok, amiket nagyobb projectnel mar kotelezo megvalositani, es ha nem PDO-t hasznalsz, akkor pontosan userspace-ben (php-ban) kell megvalositani, ami pedig pont ellentetes a te allitasoddal (pdo == tobb php osztaly, etc.).
Raadasul ha nem hasznalsz OOP-t, vagy legalabb kod ujrahasznositast, akkor ugyanazt a feladatot sokkal tobb sorbol fogsz megoldani, es egy ilyen projectnel mar pontosan az lesz a lassu, hogy a szukseges kod 10x-eset kell a parsernek/interpreternek feldolgoznia, szemben azzal, hogy ha ujrahasznosithato fuggvenyeid, osztalyaid lennenek, akkor kod parseolasa helyett(lassu io), tobb ram + cpu kellene (olcso, es konnyen skalazhato).

Az OOP szemléletmód PHP alatt ezért nem célravezető olyan feladatra, ahol performance-re lehet szükség.

egyetertek, viszont oda lehet, hogy nem a PHP a legmegfelelobb eszkoz.
a vilagon eleg nagy rendszerek elfutkorasznak PHP-ban, sot OOP szemleletu keretrendszerekkel irva, es elbirjak a terhelest (megfelelo tervezes es infrastruktura mellett).
Persze lehetseges, hogy neked nagyobb rendszered van, mint a facebook-nak, csak kevesse valoszinu.

Minden mindig egyszerre bent van a memóriában: user objektum, termék objektum, kosár objektum, cikk objektum.... Ahelyett, hogy csak az ID-juk lenne bent egy tömbben.

az van benne, amire szukseged van.
ha csak az id-ra van szukseged, akkor az van benne, ha mar meg kelle jeleniteni a kosar tartalmat a weboldalon, ott mar nem eleg az id, le kell kerned a perszisztenciaretegbol, es hopp, mar memoriaban van.

nem a PHP hibaja az, ha a szuksegesnel tobb php modult toltesz be, ha a szuksegesnel tobb adatot kerdezel le, ha a szuksegesnel nagyobb OOP reteget hasznalsz.
ez a fejleszto hibaja, nem az eszkoze.

Nemrégiben volt egy PHP-s állásmegbeszélésem, ahol a Fejlesztési vezető Úr vizsgáztatott ezekből a három betűs szavakból, hogy mennyire ismerem őket, mire használnám, stb stb. PHP alatt kivételkezelés? OMG? :))

eleg ijeszto, ha nem ismered el a kivetelkezeles letjogosultsagat.
hogyan kezelsz hibat egy olyan helyzetben, ahonnan nincs normal visszateresi ertek?
(pl. autoloader, __construct, etc.)
ha exception-t dobsz, akkor lokalisan el tudod kapni a hibat, a scope-ban ott van minden valtozo, hogy felold vagy lelogold a hibat.
ha trigger_error-t hasznalsz ilyenkor, akkor vagy @-tal kell jatszanod (ami csunya, lassu, alapbol lefut ra a globalis error_handler, raadasul csak stringbuveszkedessel (error_get_last()-bol kiszedegetni a hibauzenetet) lehet megkulonboztetni a kulonbozo hibakat), vagy globalis error_handler-bol kell lekezelned a hibat, ahol mar nincs meg az eredeti scope-od, nem tudod folytatni mondjuk a hiba lelogolasa utan a batch folyamat futasat a kovetkezo elemtol.

A vicc, hogy elvileg hír-portálmotort fejlesztenek, viszont ha ránézel arra a weboldalra, amit az a komoly "motor" kiszolgál, akkor azt mondanád, hogy 3 nap alatt összekattingatod joomlában.

A BBC pl. drupal-t hasznal, de ez nem azt jelenti, hogy 3 nap alatt ossze lehet kattingatni egy BBC nagysagu (terheles, rekordszam) oldalt drupalban.
A google.com-ot latszolag 3 nap alatt ossze lehet kattingatni (ha csak a kulcsint nezed), de te sem gondolod komolyan, hogy ez igy van.
Tehat ne a kulcsiny alapjan merd fel egy feladat meretet.

A fejlesztési vezető egyértelműen javaból tanult át. Én PHP-san tudok php-t programozni, ő meg Jávásan.

nekem inkabb ugy tunik, hogy az ottani fejlesztő tud programozni(PHP-ban is), te pedig elertel egy szintet, ahol mar nagyjabol minden feladatot meg tudsz oldani valahogy, es nem latod be, hogy nem mindig a te megoldasod a legjobb megoldas egy problemara.

Na, egy a lényeg: a PHP az nem Java vagy C++, kezeljük a helyén: ne írjunk 10 ezer soros programot benne, mert lassú lesz. Nem a futtatás, hanem a program értelmezése.

1, ugyanarra a feladatra az OOP megoldas nem feltetlenul tobb sor kod (sot!).
2, a C-ben irt php extension-ok(pdo, spl) hasznalataval csokken a php kodsorok szama, ergo kevesebbet kell parse-olni.
3, van byte code cache php-hez (xcache, apc, zend optimizer, etc.)

tudom, erre is már létezik megoldás a Zend háza táján, meg a facebookéknál is úgy volt hogy publikálnak valami nyílt forráskódú fordítót, azóta is pendingel a projekt

Kint van mar a Hiphop project egy joideje.
http://github.com/facebook/hiphop-php

summazva: gondolom nem erdekel, de szakmailag most leepitetted magad a szememben, jobb fejlesztonek gondoltalak az eddigi hozzaszolasaid alapjan.

Tyrael

Nálam jóval tapasztaltabb kollégáim már szarrá heggesztették a stuffot, hogy optimálisan menjen; amit írtál, abban igazad van (ezért is volt benne egy "(is)"), azonban minél kevesebb dolgot (PDO) forgatsz bele a php -ba, annál élvezetesebb lesz a php-fcgi erőforrás-felhasználása.
Kiváló dolog az OOP, csak nem mindenre, nem minden körülmények között.

Nem utolsó sorban az uj verzio is ojjektumorientált. :)

'lekene sslje'

azenoldalamponthu

akkor oda eleg rossz valasztas volt a symfony.
ettol fuggetlenul ugy gondolom, hogy ha a dailymotion-t elviszi a symfony (najo, nekik mar a 2es ketyeg alatta, de hasznaltak az egyes szeriat is) akkor elvihetne azt is, amire ti hasznaljatok.
ha a memoria a szuk keresztmetszet, akkor van egy tippem hogy mernokoraba dragabb lesz atirni az alkalmazast, mint ha beraknatok meg 1-2 szervert a frontend clusterbe (persze ha nem skalazhato a rendszer, akkor szopo, de a mostani atirassal is csak halogatjatok a ve'get)

Tyrael

Here is an example of a procedural program:

<?php

print "Hello, world.";

?>

Here is an example of an object-oriented program that achieves the same objective:

<?php

class helloWorld {
function myPrint() {
print "Hello, world.";
}
}
$myHelloWorld = new helloWorld();
$myHelloWorld->myPrint();

?>

Lehetne statikus metodussal irni igen, es valoban gyorsabb is lenne mint peldanyositassal, de abban igaza van hogy a statikus hivas is min 5* lassabb mint ha siman proceduralisan csinalnad.
Viszont ez a veszteseg lopikula. Mar tobb helyen kifejtettem, de iszonyat ritka az hogy a PHP legyen a szuk keresztmettszet. Altalaban vagy az SQL vagy a Cache reteg ami nem birja a terhelest.
Egy igazan nagy projektet meg proceduralisan irni halal (tudom mert csinaltam mar).
Amit az OOP elvesz teljesitmenyben azt boven visszaadja fejlesztesi idoben, atlathatosagban es megbizhatosagban. Lehet szeretni meg nem szeretni, de az biztos hogy nem igazan fog bekerulni az ember normalis helyre PHP-t fejleszteni ilyen hozzaallassal.
Az mar mas kerdes hogy a legtobben az OOP-t is szarul hasznaljak, es ehhez is kell a tapasztalat hogy ismerje a gyengeit meg az elonyeit, hogy tudja mit milyen kereteken belul szabad. De ez minden nyelvre es minden programozasi metodikara igaz imho.

------------------
http://www.youtube.com/watch?v=Sf8cM7f6P2I

"Egy igazan nagy projektet meg proceduralisan irni halal (tudom mert csinaltam mar)."
Projekttol is fugg. Ahol a PHP kod minimalis, es elsosorban a HTML az, ami tomentelen, ott pl. nem halal. Raadasul egy kis C-s attituddel meg elvezetes is. Tudom, mert csinaltam mar ilyent.

"Amit az OOP elvesz teljesitmenyben azt boven visszaadja fejlesztesi idoben, atlathatosagban es megbizhatosagban."
Ezzel van egy ici-pici gond. A fejlesztesi ido az van 1x, a teljesitmeny visszafogasa meg folyamatosan. Inkabb fejlesszen a fejleszto hosszabban jo teljesitmenyu kodot, mint osszedobjon gyorsan egy iszonyat lassut. Ha kell, irja meg proceduralisan a kodot, ha ez hozza ki az adott alkalmazasnal a legjobb teljesitmenyt.

A tobbi meg fejleszto kerdese. Sajnos nagyon keves ember van, aki egyaltalan ert a PHP-hoz annyira, hogy tudja, mit hogyan kell normalisan megcsinalni. Rengeteg, magat PHP kodernek/fejlesztonek hivo emberke van, aki egy-ket tutorial utan mar asznak erzi magat, kozbe meg a tudasa sehol nincsen.

PS: a kerdesemben egyebkent a felvetett Java-s problemara kerdeztem ra, es nem PHP-s kerdes volt.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

"zzel van egy ici-pici gond. A fejlesztesi ido az van 1x, a teljesitmeny visszafogasa meg folyamatosan. Inkabb fejlesszen a fejleszto hosszabban jo teljesitmenyu kodot, mint osszedobjon gyorsan egy iszonyat lassut. Ha kell, irja meg proceduralisan a kodot, ha ez hozza ki az adott alkalmazasnal a legjobb teljesitmenyt."

Ezzel nem igazan ertek egyet. Teljesitmenyben nem vesztesz annyit hogy megerja inkabb proceduralisan fejleszteni. Persze vannak kirivo esetek, es nagyon meg kell nezni mit es hogyan fejlesztesz le OOP-ben.

------------------
http://www.youtube.com/watch?v=Sf8cM7f6P2I

'A fejlesztesi ido az van 1x, a teljesitmeny visszafogasa meg folyamatosan. Inkabb fejlesszen a fejleszto hosszabban jo teljesitmenyu kodot, mint osszedobjon gyorsan egy iszonyat lassut. Ha kell, irja meg proceduralisan a kodot, ha ez hozza ki az adott alkalmazasnal a legjobb teljesitmenyt.'

Szép világ lenne, ha valóban így lehetne csinálni.
A php projektek 95%-ánál 2 kérdés a legfontosabb:
1. működik stabilan?
2. mennyi idő alatt készül el?

Az ember persze falra mászik ezen, ha c felől jött, de minél előbb megtanulja a leckét annál jobban fog keresni.

Persze megvan a maradék 5% is felüdülésnek, ahol valóban nem az képezi az érdemi agymunkát, hogy hogyan tudsz legköltséghatékonyabban gányolni, de abból nem élnél meg.

persze, irjon C-ben extensiont PHP-hoz assembly betetekkel, nehogymar a rendszergazda ki kelljen hogy nyisson egy "hogyan epitsunk clustert", vagy "hogyan configuraljunk adatbazisszervert".
sajat szememmel lattam mar olyat, amikor a rendszergazdak folyamatosan piszkaltak a fejlesztoket, hogy lassu a kod, es a vegen(egy csomo optimalizalas utan) kiderult, hogy a mysql szerver egy default 64 megas configgal futott a 8? 16? (mar nem emlekszem pontosan) GB rammal rendelkezo adatbazisszerveren.
Az igazsag altalaban a ketto kozott van, optimalizaljunk annyit, hogy rovid/kozep tavon elfogadhato legyen a teljesitmeny, es tervezzuk ugy a rendszert, hogy a jovoben legyen hely noni.

ps: azzal egyetertek, hogy sok a kokler php-s, de
- altalaban nem a php szokott a szuk keresztmetszet lenni.
- a webszervereket konnyu skalazni (hala a stateless shared nothing architechturanak).
- a rendszergazdak hajlamosak rakenni mindent a fejlesztokre.
- a fejlesztok hajlamosak rakenni mindent a rendszergazdakra.
- altalaban nincs szukseg a weben nagy szamitasigenyu feladatokra (apokalipszis modelezes, etc.).
- altalaban olcsobb berakni par uj szervert, mint ujrairni az alkalmazast jobban 1 evnyi emberora alatt.
- nem a lassusag szokott problemas lenni uzleti szempontbol, hanem a kiszamithatatlansag:
-- ha nem jol strukturalt, jol dokumentalt, ergo atlathato a rendszered, akkor nehez bebizonyitani, hogy jol mukodik.
-- ha nem jol mukodik, akkor a hiba megtalalasahoz es kijavitasahoz szukseges ido nagyon nagy szorast mutat.

Tyrael

irok en is egy peldat.
kicsit kozelebb maradva a php beepitett osztalyainal.

proceduralis: 


<?php
$fp = fsockopen("www.example.com", 80, $errno, $errstr, 30);
if (!$fp) {
    echo "$errstr ($errno)<br />\n";
} else {
    $out = "GET / HTTP/1.1\r\n";
    $out .= "Host: www.example.com\r\n";
    $out .= "Connection: Close\r\n\r\n";
    fwrite($fp, $out);
    while (!feof($fp)) {
        echo fgets($fp, 128);
    }
    fclose($fp);
}
?>

kesz komponens: 


<?php
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, "http://www.example.com/");
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_exec($ch);
curl_close($ch);
?>

masik pelda:

strukturalt: 


<?php
$link = mysql_connect($host, $user, $pass);
if (!$link) {
    die('Could not connect: ' . mysql_error());
}
$db_selected = mysql_select_db($db, $link);
if (!$db_selected) {
    die ('Can\'t use foo : ' . mysql_error());
}
$result = mysql_query($query);
$count = mysql_affected_rows($result);
print("Deleted $count rows.\n");
mysql_close($link);
?>

oop+kesz komponens 


<?php
$dbh = new PDO ( $dsn, $user, $password, $options ) ;
$count = $dbh->exec("DELETE FROM fruit WHERE colour = 'red'");
print("Deleted $count rows.\n");
?>

Tyrael

A masodik pelda masodik kodja nem jo, nincs ellenorizve sem a handler, sem a visszakapott ertek (ez foleg azert szembetuno, mert az elso kod agyonellenoriz mindent). Ebbol olyan szep hiba tud lenni, ha a dsn pl. nem jo, hogy ihaj.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( geronimo | 2010. 06. 07., h – 09:38 )

Miért van a kettő között VAGY kapcsolat?
--
kövi

Karaktertábla szerint: ⊻ U+22BB XOR
Tanulmányaim szerint pedig nem ⊕ (U+2295 CIRCLED PLUS) hanem ⊗ (U+2297 CIRCLED TIMES) volt a kizáró vagy.
Fene se gondolta volna, hogy ennyire nincs egyetértés ☺ 

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

Egy aprosag: azert "(+)"-t irtam, hogy tagoltabb legyen. Amugy fenntartom, hogy a topik cimeben nem halmazokrol van szo, hanem logikai muveletrol (Boole algebra rulez), ugyhogy szemantikai hiba volt idekeverni a halmazokat...

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

Igazából azt is tedd hozzá, hogy hiányosak a matematikai ismereteid, ami nem lenne gond, ha nem próbálnád meg ezt erővel ellensúlyozni.
Persze nem lett volna itt semmi gond, ha elismered, hogy bocs fiúk, rosszul tudtam, vagy nem ismertem ezt a részt, ez van. De újfent úgy érzem (volt már ilyen többször), hogy te nem tudsz veszíteni.
C'est la vie ... ez van...

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

Csak a torteneti huseg kedveert: inverz khi (ha jobban tetszik: chi) negyzet az algoritmus neve, amit hasznalok. De vita ide, flame oda, ez szamomra nem erv az allaspontom mellett; tavol legyen, hogy azzal akarjak ervelni/felvagni, hogy "de en jobban tudom, mert nezd mit csinaltam..." Szoval vegyuk ugy (most az egyszer), mintha nem is csinaltam volna...

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

Erdekelne, hogy az inverz chi-negyzet eloszlast hogyan lehet klasszifikaciora hasznalni, foleg, hogy tud-e nem binaris klasszifikaciot is az algoritmus? Eppen egy olyan problemaban vagyok, hogy viszonylag kisszamu cimkezett es nagyszamu nem cimkezett dokumentumot kell feldolgoznom hatekonyan, eddig amit talaltam ra, az egy Expectation-Maximization + Naiv Bayes alapu algoritmus, http://www.kamalnigam.com/papers/emcat-mlj99.pdf
Bar el fogom olvasni ezt is: http://www.kamalnigam.com/papers/thesis-nigam.pdf, ebben van szo arrol, hogy a cimkek hierarchiaba szervezhetoek, ami eppen illik a problemara, amit meg kell oldanom.

Az algoritmus onmagaban nem klasszifikal, mindossze egy (aggregalt) valoszinuseget ad vissza, amit aztan mi hasznalunk szortirozasra. Az valo igaz, hogy a bayes-i algoritmus nehezen ad ~0.5 koruli erteket, es joreszt a 0 ill. 1 kozelebe szorja az eredmenyeket. Az inverz khi-negyzet eredmenyebol azonban tudunk (unsure) erteket is adni/szarmaztatni, azaz 3-allapotu eredmemenyt: ham, spam, unsure, ill. en az utobbi ketto koze csinaltam egy 'possible spam' savot is.

Hallottam mar olyan felhasznalasrol, hogy a leveleket nem csak ham-spam kategoriakba sorolja a program, de pl. megkulonbozteti a magan levelezest az uzletitol (nyilvan egy 2. token adatbazissal).

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

Hm, ha egy db szamot (valoszinuseget ad vissza), akkor az binaris klasszifikacio, es megadja a ket kategoria kozul az egyikbe eses valoszinuseget,nem? Amiket eddig lattam tobbkategorias klasszifikatorokat, ott (nyilvan) minden kategoriara megadta az adott kategoriaba eses valoszinuseget.

Hmmm, bennem eddig az elt, hogy az a binaris, aminek 2 allapota van (pl. 0 ill. 1 korul). Az inv. khi2 sokkal inkabb "analog", mint a bayes-i, mert nem csak ezt a ketfele eredmenyt ismeri. Egyebkent az elobbi nem csak azt szamolja ki, hogy a level mekkora valoszinuseggel spam, hanem azt is, hogy mekkora valoszinuseggel ham, es ebbol a 2 ertekbol allitja elo a kombinalt eredmenyt. Igy az is lehet, hogy a level nem hasonlit a hamekre, sem a spamekre, ill. akar az is, hogy nagyon hasonlit a hamekre, de a spamekre is.

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

Ez binaris klasszifikacio, mert ket, egymast kizaro kategoriaba osztod a leveleket (SPAM es HAM), ha jol ertem. Ha egy p valoszinuseggel tudod, hogy a level SPAM, akkor nyilvan 1-p valoszinuseggel tudod, hogy HAM (ezert is baromsag a szorcs.hu tervezojetol az a kijelentes, hogy a nem relevans talalatokat megtalalni konnyebb, mint a relevansakat, a ket dolog, mivel komplementer dolgok, ugyanazt jelentik). Persze ez akkor igaz, ha a ket kategoria diszjunkt, azaz nincs olyan level, ami SPAM es HAM is egyben. Ha ez inkabb valamifele hasonlosagi metrika akar lenni 0 es 1 koze skalazva (tehat ennyire hasonlit SPAM-re es ennyire hasonlit HAM-re), akkor az nem klasszikusan binaris klasszifikacio, hiszen egy 2D parameterteren (ez ennyire SPAM, ez ennyire HAM) helyezed el a levelet. Csak akkor nem tudom, mikent lesz belole megis a vegen binaris dontes: ez a level SPAM, ez a level HAM.

mert ket, egymast kizaro kategoriaba osztod a leveleket (SPAM es HAM), ha jol ertem.

Azt is lehet, de van mod egy kozepso zonat is definialni (mert tud valoszinuseget oda is szorni), es igy mar 3-allapotu az eredmeny.

Ha egy p valoszinuseggel tudod, hogy a level SPAM, akkor nyilvan 1-p valoszinuseggel tudod, hogy HAM

Az inv. khi2 nem a felteteles valoszinuseget hasznalja, es itt egy kicsit komplikaltabb is, mert lehet, hogy a level 70% valoszinuseggel spam, de 45% valoszinuseggel ham (2 szamitasrol van szo!)

Persze ez akkor igaz, ha a ket kategoria diszjunkt, azaz nincs olyan level, ami SPAM es HAM is egyben.

Fentebb irtam, hogy van olyan level, ami olyan, mint a spam, de van hamre utalo vonasa is. Es valoban vannak olyan levelek, amelyek lattan gondolkodunk, hogy ez most mi....

mikent lesz belole megis a vegen binaris dontes: ez a level SPAM, ez a level HAM.

Ugy, hogy huzunk egy limitet, ami folott spamnek tekintjuk a levelet. Az alatt meg lehet 'possible spam', 'unsure' ill. 'ham'. Mondom, igy akar 4-fele is szortirozhatjuk a leveleket.

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

"Ugy, hogy huzunk egy limitet, ami folott spamnek tekintjuk a levelet."
De minek a limitjet? Amint mondtad, ket szamitas van, az egyik megadja, hogy mennyire spam, a masik meg, hogy mennyire ham a level. A ketto nyilvan nem fuggetlen egymastol,valamennyire korrelal. Ugy van, hogy csinalsz egy aggregatumot, amelyben a spamscore x sullyal, a hamscore meg y sullyal szerepel, es ez alapjan dontesz? Ertem, hogy akar 4fele is klasszifikalhatnad a leveleket, akar a spamscore es a hamscore elteresen alapulva. Az nem vilagos, hogy a ket valoszinusegbol hogy lesz egy ertek, ami alapjan klasszifikalsz?

Ok, akkor a gyengebbek kedveert, szajbaragosan. A topik cime "...PDO-t vagy SPL-t". Valaki megjegyezte, hogy akkor ez most "is-is"? Erre a valasz egy wikipedia link, amire megjegyeztem, hogy milyen hulye jelolesek ezek, plusz amire mar akkor is az elavult (esetleg "nyugati") jelzot alkalmaztak, amikor en tanultam a Boole algebrat. Ennyit akartam mondani. Valaki idekeverte a halmazokat, aminek a topik cime kontextusahoz aligha van (szoros) koze. Akkor pedig marad a logikai kontextus, amiben viszont az "OR" kapcsolatnak (+) a jele. Ez nem osszekeverendo az "XOR" muvelettel, mivel a \/-re szinten (\/) jelolessel hivatkoztam. (Ha ezt a mondatot nem erted, akkor szolj, es kifejtem reszletesebben). Menet kozben meg idetoppan ez a btami nevu marharepa, es elkezd alazni. Biztos jo oka volt ra.

Szoval megegyszer, lassan, hogy te is megertsd: ha hianyosak is a matematikai ismereteim (noha ez itt most nem nyert igazolast, legfeljebb jol megpufoltetek egy szalmababut, amihez gratula), itt logikai muveletrol volt szo, aminek a jele valtozatlanul "+", es nem "\/". Troll etetesnek vege.

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

"Valaki idekeverte a halmazokat"-te voltal az elso, aki halmazokat emlitett a szalban.
A logikai muveletek jele pedig tovabbra sem +, hanem \/, nezd meg az alabbi matematikai logikai muveket:
http://en.wikipedia.org/wiki/Boolean_algebra_(structure)
http://www.ttk.pte.hu/matek/ltoth/A%20matematikai%20logika%20alapjai,%2…
http://www.math.klte.hu/~kovacsa/Logika.pdf
http://www.inf.u-szeged.hu/oktatas/Tempus/logika.doc
http://hu.wikipedia.org/wiki/%C3%8Dt%C3%A9letlogika
http://mathworld.wolfram.com/OR.html

Mutass akar egy olyan, matematikai logikaval foglalkozo muvet, amely +-t hasznalja a logikai VAGY leirasara.

A topik cimenek problemajat teljesen jol leirja a Boole algebra (amiben a "+" a kerdeses jel). Ok, jogos: elkerulte a figyelmemet, AND megtevesztett a jobb felso sarokban lathato VAGY-kapu, (ami garantalan nem a matematikai logika tartomanya, sokkal inkabb a logikai algebrae), hogy a hivatkozott cikk nem egeszen ezzel foglalkozik, es ezert hasznal (ebben a kontextusban) szokatlan jeloleseket...

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

Hat nem atvertek a szemetek, amikor pedig igy tanitottak a kozepiskolaban, de meg a foiskolan is?! http://en.wikipedia.org/wiki/Two-element_Boolean_algebra

De _veled_ nem akarok errol vitatkozni, mert a taho viselkedeseddel egy idore leszerepeltel elottem, ugyhogy szallj le rolam mucika. Most avesz egy kicsit pihizni: tudod pron vid, meg csattogtatas. Jobban erzed magad a vegen, na szevasz...

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

Amit linkeltel, az _egy konkret_ Boole-algebra, amelynek alaphalmaza a {0,1} halmaz. Itt persze a mod2 osszeadas ugy viselkedik (izomorf a keletkezett struktura az absztrakt Boole-algebraval), mint a logikai VAGY muvelet, illetve a szorzas ugy viselkedik, mint a logikai ES muvelet. Persze ez csak egy konkret Boole-algebra, lehet definialni Boole-algebrat az {I,H}, vagy a {kakas, buszkerek} halmazon is, a lenyeg, hogy ketelemu legyen. Meg mindig fenntartom, hogy az absztrakt esetben \/ a konvencio szerinti jeloles, ebben a konkret esetben meg a +, lehetne olyan eset, hogy a !-t vagy a ~-t definialjuk ugy, hogy aszerint viselkedjen, mint az absztrakt definicioban szereplo \/.

Oke, akkor mennyi kakas+buszkerek? :) Ezt csak akkor tudod megmondani, ha megfelelteted a kakast az absztrakt Boole-algebra igaz elemenek, a buszkereket az abszrakt Boole-algebra hamis elemenek, es a +-t megfelelteted mondjuk az absztrakt Boole-algebra ES elemenek (direkt ES, a pelda kedveert). Addig amig nem definialod a konkret strukturaban a + es * jelenteset, addig nem lehet tudni, hogy az az abszrakt struktura melyik relaciojanak a megfeleloje.

Most akkor igen/nem, vagy 1/0? Az, hogy hogyan _jelolod_ a konkret muveletet, fugg attol, hogy hogyan nevezed a _konkret_ alaphalmaz elemet a _konkret_ Boole-algebraban. Az altalanos absztrakt esetben a muvelet jele \/, az alaphalmaz ket eleme pedig A es B. A te esetedben: mennyi igen+nem?

Oooo, nagyon ertelmetlen dolgokrol vitaztok. Szerintem mondjuk azt, hogy PDO || SPL es akkor mindenki boldog, mert ez 1337 nyelven van, es mindenki erti. A tobbi jelolesmod meg maradjon meg a matematikusoknak.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( numen v | 2010. 06. 07., h – 17:08 )

Nem vagyok PHP fejlesztő, a PDO-t valamikor néztem, hogy „de jó lenne használni”, de mivel saját célra kódolok, sose volt szükségem arra még, hogy ezzel könnyítsem meg a kódom hordozhatóságát.
SPL-ről eddig még csak mint Shakespeare Programming Language hallottam… ☺ 

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

( hrgy84 | 2010. 06. 08., k – 06:46 )

Nekem a mysql_connect() pont eleg arra, amire nekem kell. Ja, es egyebkent nem vagyok PHP fejleszto, ugyhogy a kerdest "Ha PHP fejleszto lennek" atfogalmazassal valaszoltam meg, hogy ertelmeset nyomjak.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.