Staking our future on PHP
Javaslatok a PHP jövőjét illetően
■ 
Friss blogmarkok
- Web Akadálymentesítési Útmutató (WCAG) 2.1 – nyilvános munkaterv – Megjelent a WCAG (Web Akadálymentesítési Útmutató) 2.1 nyilvános munkaterv (0)
- MongoDB Apocalypse Is Here as Ransom Attacks Hit 10,000 Servers – Több tízezer védtelen MongoDB szerverre csaptak le hackerek (2)
- 12 Signs You’re Working in a Feature Factory – A cél nélküli funkciógyártás néhány tünete (0)
- Translatable, custom dates in Twig templates of Drupal 8 – Saját dátumok megjelenítése, fordíthatóan a Drupal 8 smink rétegével dolgozva (0)
- NativeScript – Cross-Platform Native Development with Javascript – Fejlesszünk natív mobilalkalmazást JavaScripttel (0)
- GitHub Security Update: Reused password attack – Érdemes bekapcsolni a kétfaktoros azonosítást, ha a GitHub jelszavunkat más oldalakon is újra felhasználtuk (17)
- UX Design könyv – Hogyan tervezz felhasználóbarát és szerethető alkalmazásokat? (0)
- Introducing unlimited private repositories – Megváltozik a GitHub díjszabása: minden előfizetéshez korlátlan számú privát repository jár (0)
- Drupal 8 Twig: add custom CSS classes to menus (based on menu name) – Saját elképzeléseink szerinti CSS osztályok (automatizált) hozzáadása a Drupal 8 menüihez (0)
Cikkajánló
Bártházi András:
MySQL 5.0: karakterkódolások
Poetro:
Hierarchikus adatkezelés SQL-lel PHP-ben I.
Baranyai László:
Barátságos hibaüzenetek - 404
Friss csiripek
Csiripek betöltése…
Aktív fórum témák
Új fórum témák
Archívum
| H | K | Sze | Cs | P | Szo | V |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 1 | 2 | 3 | 4 | 5 |
Abszurd
Tulajdonképp csak azt szeretném megtudni, hogy szól-e ez a poszt másról, mint az évenként szokásos sírásról, miszerint "mi legyen a PHP-vel a jövőben?". Ezt a kérdést ugyanis visszatérően felteszik, aztán általában nem történik semmi jelentős.
Az egész PHP-s életérzés része, hogy egy koncepciótlan trágyadombon kell professzionális vagy "félprofesszionális" webalkalmazásokat írni. Mindeközben a Zend ül a kódokon és ontja ki magából az olyan típusú keretrendszert, amitől Rasmus Lardorf-nak az összes haja szála az égnek áll (és ennek szinte minden előadásán hangot is ad). Abszurd.
az ijeszto az, hogy kb. 5
- a csereljuk ki a needle-haystack sorrendjet
- a legyen xy feature (ahol xy mar egy evek ota letezo feature a php-ben)
- legyen tobb OOP
- legyen kevesebb OOP
- legyen a php node.js, mert az most meno
szoval elegge esz nelkul dobaljak be a kalapba az otleteket az emberek.
Tyrael
Tény, hogy lenne mit javítani rajta...
Épp időszerű volna... :/
Tanulhatna tőle ezt-azt ez tény és való, de azért nem volna okos ötlet egy-az-egyben lemásolni az egészet.
Mundjuk a
$_GET,$_POST,$_FILES,$_COOKIE, meg a többi szuperglobális szerintem (is) eltakarodhatna a náthásba, helyette szvsz jobban mutatna még akár egy szem$_REQUESTis – ha már mindenáron ragaszkodnának páran a szuperglobálisokhoz – , amiben van a HTTP metódus, verzió, kérés fejlécek, meg a kérés törzse, aztán azt dolgozza fel magának a programozó, ahogy az jól esik neki.Épp időszerű volna...
altalaban aki ezt tartja legfontosabb problemanak, az nem tudja megmondani, hogy melyek azok az esetek, ahol nem stimmel a sorrend, es meg kellene valtoztatni.
amugy egyetertenek a szandekkal, csak szerintem nem akkora problema amennyire sokan emlegetik, egyszeruen ez ragadt meg az emberek fejeben mint hatalmas problema.
megint nem mondtal semmi konkretumot. az event kezeles sokan emlegettek de altalanossagban bedobni olyan, minthogyha en azert tuntetnek, hogy node.js-ben/javaszcriptben/actionscriptben is lehessen siman strukturálisan/proceduralisan programozni.
tehat legyen benne sleep, es legyenek olyan blockolo hivasok, amivel megirhatom ugyanazt a kodot, amit most csak event handlerek segitsegevel.
bar most nagyon divatos, de szerintem nem kell minden programozasi nyelvnek teljesen event-driven-nek lennie, viszont valamilyen lightos(pl. GIL: http://en.wikipedia.org/wiki/Global_Interpreter_Lock) thread kezelessel teljesen jol event-drivenne lehetne tenni a PHP-t is, anelkul hogy nagyon bele kellene nyulni a kodba.
ezt en is szorgalmaztam mar: https://twitter.com/#!/Tyr43l/status/5318217312501760
itt az implementacio moriyoshi-tol:
https://github.com/moriyoshi/php-src/blob/PHP_5_3-threading/ext/threading/README
es most latom hogy valaki portolta Pthreads-re is:
https://github.com/alecgorge/php_threading
a nehany globalis valtozo felszamolasaval kapcsolatban nem latom hogy ki nyerne ezen barmit is. az OOP huszarok ugyis objecteken keresztul fogjak elereni ezeket az infokat, szoval nekik tok mindegy, hogy hol van eredetileg, a tobbiekkel viszont kibaszas lenne, mert N+1 helyen at kellene irni a meglevo kodbazist.
Tyrael
Szerintem a PHP nem sokat
Szerintem sok javaslat körül (mint a threading is) ott lebeg a ki nem mondott kívánság, hogy a PHP futhasson application serverként. Ehhez viszont szerintem a gyökeresen kellene megváltoztatni az egészet. Én szeretem a PHP-nak ezt a tulajdonságát, ti. hogy a per request execution jól igazodik a HTTP "stateless"-ségéhez, és legtöbb esetben nem a PHP a bottleneck teljesítmény szempontból.
Számomra sokkal fontosabb előrelépés lenne például a tesztelhetőség, a rengeteg függvénygyűjtemény összerendezése objektumorientált sémára (mint ahogy ez jelenleg zajlik is, de sajnos túl lassan).
Egyébként az "OOP huszár" úgy hangzik, mintha ez valami elkerülendő ostobaság lenne :P A függvény paraméter sorrend megváltoztatája mint javaslat nevetséges.
Szerintem a PHP nem sokat
az osszes olyan esetben, ahol szukseg lenne az async hivasokra, ott threadinggel ez kivalthato lenne.
en is inkabb maradnek a shared-nothing megoldasnal, jobban skalazodik (php-ban alapbol csak a default session handler ami skalazodasi szempontbol problema, minden mas szempontbol az adatbazisra van attolva a skalazodas problemaja), szoval egyetertek veled.
ezt kifejthetned reszletesebben. marmint hogy mi a problemad a php tesztelhetosegevel?
illetve hogy mely fuggvenynyujtemenyre gondolsz, a php-ban levokre? vagy a PEAR-ben? vagy a kulonbozo komponens libekre(Zend, Zeta, etc.)?
alapvetoen OOP parti vagyok, de sokszor latom azt, hogy bizonyos emberkek nem racionalisan hasznalnak eszkozoket, patterneket, hanem "divatbol".
pl. sokadszor futok ossze olyann emberrel, aki ki szeretne szedni a php-bol a @-ot, mert hogy neheziti a debugolast, es ugyis csak a ganyhuszarok hasznaljak.
aztan mikor bedob az ember egy ket valo eletbol vett peldat, hogy "de hogy oldanad meg azt, hogy nem tudod elore hogy ott van-e az adott cache-file, es a file_exists es a beolvasas kozben letorolheti egy masik process, viszont le kell tudnod kezelni az esetlegesen kivaltott hibat es nem az error handlerbol szeretned ezt, ahol mar nincs meg kello mennyisegu informacio", vagy ilyesmi, akkor megy a hummoges.
Tyrael
Probléma?
Vagy a probléma szó jelentésével nincsen tisztában. :)
Igen, kb ez az, amiért sosem
Általában a kívánságlista OO-ra:
- Legyen encapsulation, inheritence
- Legyen protected, static, stb., legyen late binding
- Legyenek mán setterek, getterek minden operátorra
- Legyen mán Dzsava...!
Általában funkcionálisra
- Ne legyen mán Dzsava!
- Dobjuk ki a settereket mer az feketemágia!
- Minek adattagot elrejteni, a programozó tudhassa hogy mi kell neki! Minek static, konstanst vagy globálist kell használni 'oszt jó' van!
- Szedjük mán ki az öröklődést, strukturált adatok tárolására elég egy Record típus is, vagy ott a tömbök!
Szóval...
Szerintem, ami bajos a PHP-vel:
1.) Igen is kusza az API-ja, igenis zavaró a needle-haystack probléma, és igenis probléma. Tény, hogy nem akkora mint sokan mondják, de attól mert kicsit az csak, még továbbra is probléma marad. Probléma, hogy a string függvények fele str_-sal kezdődik, a másik fele meg nem, és egyáltalán semmiféle logika nincs benne, hogy melyik miért.
2.) Problémás a unicode/UTF-8 kezelés, az mb_string kiterjesztés nem implementál egy csomó string fgv.-t.
3.) Sebességoptimalizálás. Akár bundled APC-vel, akár bármivel, csak legyen.
4.) Várom a natív típusok bundled OO implementációját. Az SPL ezirányú törekvése - khm - gyengusz. Vagy ha ez nem eléggé "PHP-like" dolog, akkor teljes operator overloading-ot.
5.) Szükség lenne multithreading-re.
6.) Szükség lenne arra, hogy a PHP-s kódok binárissá fordíthatóak legyenek, amit akár egy VM is futtathat, a lényeg az, hogy korrekt enterprise-level megoldásokat lehessen szállítani PHP-vel, míg a script parser-es (mondjuk LAMP) megoldások megmaradhatnak a "félprofesszionális" alkalmazások- és a "scriptpistikék" számára. Előfordulhatna az is, hogy multithreding-et csak a VM-ben támogatnám, mert "normális" esetben felesleges, sőt veszélyes is lehet.
7.) Event driven-séget feleslegesnek tartom, a keretrendszer dolga legyen az implementálás.
8.) Összeszedett, komoly, hivatalos keretrendszer kiadása. Lehetőleg olyané, amivel RAD-szerű környezetben lehet fejleszteni (.NET, Java?)...
Igazából azt sajnálom, hogy a PHP még ennyi év után is tényleg babajáték. Valóban, meg lehet vele oldalni rendkívül komplex alkalmazások felépítését, de nincs egy jól átgondolt és professzionális fejlesztésre alkalmas kerete ami a korhoz igazodna. Emellett ott a PHP évek óta igérgetett 6-os főverziója, amiből ha a fejlesztés így halad, 2021-ig biztosan várni kell...
- 1, szedd ossze a
- 2, 22.-en lesz egy eloadas Andrei Zmievski-tol a phpcon-on: The Good, The Bad & The Ugly: What Happened to Unicode in PHP 6 http://phpcon.org/speakers/#zmievski
szvsz ha nem akartak volna akkorat markolni a full unicode supporttal es kozben meg visszafele kompatibilisek is maradni, akkor nem lett volna nagyjabol kidobott ido/energia a php6 fejlesztese.
- 3, APC beepiteset a core-ba nem tamogatom szemely szerint, tulsagosan experimental benne egy csomo feature, meg amugy is xcache parti vagyok.
production kornyezetben amugy imho mar most is mindenki hasznal valamilyen opcode cache-t, szoval akiknek szukseguk lenne a plusz teljesitmenyre, azoknak ez a lepes mar nem segitene.
viszont Dmitry Stogov reszerol eleg sok performance improvement kerul be a nyelvbe, pl. az 5.3 a sok uj feature melle meg tudott hozni egy laza 20%os gyorsulast.
a php egyebkent imho nincs lemaradva pl. a python-hoz vagy a ruby-hoz kepest, de nagyobb beavatkozasok nelkul szerintem nem varhatoak jelentos gyorsulas.
pl. https://wiki.php.net/rfc/remove_zend_api
- 4, mi a bajod az SPL-es tipusokkal? amugy idonkent at szoktak szivarogni spl-es cuccok a nyelvbe, pl. spl_autoload, szoval nem elveszett dolog. operator oeverloading-ot nem tamogatnam, foleg nem ugy, hogy function overloading nincs, es nem is varhato a nyelvben.
- 5, szerintem "igazi" multithreading bekerulesere 0 az esely, internalson szepen ki lett targyalva, egyreszt a php core ugyan szalbiztos, de jelenleg kb. minden ugy van benne kialakitva, hogy csak 1 szal tudna biztonsagosan elerni az adatokat 1 futo scriptbol, plusz az atlag php fejleszto (mondjuk 98+ %) nem tudna hibatlanul mukodo multithreaded alkalmazast irni, viszont legalabb a fela megprobalna.
pedig a jelenleg blocker sync hivasokat hasznalo alkalmazasokat jol fel lehetne gyorsitani vele. :/
- 6, hiphop-php? amugy van tobb php interpreter(phc, Quercus, Roadsend) is, de a legnagyobb problema, hogy maga a nyelv ad-hoc modon van osszerakni, ezert nagyon nehez olyan interpretert csinalni, ami ugyanugy mukodik mint a zend engine. errol ment egy nagyon erdekfeszito beszelgetes itt: http://www.mail-archive.com/internals##kukac##lists.php.net/msg43428.html
- 7, ok, de ha a nyelv nem tamogatja az async utasitasokat, akkor nem tudod nagy hackeles nelkul (kulso process inditas) megoldani a normalis event driven kodot.
- 8, attol fugg mit ertesz alatta. a PEAR lett volna hivatott a "hivatalos" library gyujtemeny szerepet betolteni, de nagyon nem valtotta be a hozza fuzott remenyeket, a Zend meg kiadta a sajat lib gyujtemenyet, ami lehetett volna a kvazi hivatalos lib gyujtemeny, de ott meg a CLA alairasa tartja tavol a kozremukodoket. ennek kapcsan elindult most egy beszelgetes a kozossegen belul, egyreszt a PEAR felturbozasara, masreszt elkezdtek nehanyan dolgozni egy rubygems+bundler jellegu cucc megvalositasan, valamint szuletett egy otlet a jelenleg letezo kulonbozo PEAR repok kozponti elerhetosegevel kapcsolatban (http://blog.stuartherbert.com/php/2011/04/09/gathering-requirements-for-a-pear-channel-aggregator/ , http://packagist.org/), illetve letrejott egy http://pear.apache.org/ is az ASF tamogatasaval.
az megvan, hogy a PHP6-ot lefujtak, es ami mentheto volt az elkeszult fejlesztesekbol, azt adtak ki az 5.3-ban, illetve meg mindig nincs eldontve, hogy mi legyen a kovetkezo kiadas, bar a core fejlesztok egy kissebb csoportja mar megprobalt egy 5.4 alpha-t release-elni, de a tobbseg leszavazta, mert nem volt egyeztetes es dontes ezugyben?
ps: sorry, hosszu lett :/
Tyrael