Go PHP5! - Társulás a PHP5-re váltás sürgetéséért

PHP

A gophp5.org oldalon egy olyan társulás felhívása található, amely célul tűzte ki, hogy egyre több szolgáltató váltson PHP5-re (azon belül is 5.2 feletti verzióra). A csoportosuláshoz olyan projektek csatlakoztak, mind a Symfony, Propel, Drupal, Typo3, PHPMyAdmin. Több nagyobb amerikai tárhely szolgáltató is a kezdeményezés mellé állt, elősegítve ezzel a PHP5 elterjedését.

A kezdeményezéshez csatlakozó projektek 2008. február 5. után nem adnak ki PHP4 kompatibilis kiadásokat, ezzel a saját fejlesztési erőforrásaikat is optimalizálják, és segítenek a közösségnek a továbblépésben a PHP5 és később a PHP6 irányába - állítja a társulás honlapja.

A PHP4 immár 7 éve szolgálja a fejlesztői közösséget, de több hiányossággal is rendelkezik, amelyeket a PHP5 már régóta támogat (normális OO modell, rengeteg új függvény, új adatbázis-elérési rétegek, nagyobb teljesítmény, erősebb xml/webservice support). Sajnos azonban az újabb 5-ös kiadás nem teljesen lefelé kompatibilis, ezért sok helyen döntenek úgy, hogy a fejlesztési költségek csökkentése miatt maradnak a 4-es verziónál, és így a PHP fejlesztőcsapat sem tudja elhagyni a 4-es kiadás támogatását.

További információ: gophp5.org, Digg

( snq- | 2007. 07. 06., p – 08:11 )

>> normális OO modell
AHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA

úgyérted, hogy egy NEM OO nyelvtől, amit próbálnak valamennyire OO -á tenni, mennyit várok el? mi köze ennek ahhoz, hogy én arra reagáltam, hogy egyesek szerint már most normális benne az OO. szerintem nem az. én csak a hozzászólásra reagáltam, nem pedig a PHP-t szidtam. teljesen jól megvagyok a phpvel, bár valóban idegesít pár hiányzó dolog, de ettől még nem dobom ki az ablakon, hiszen mehetnék JAVA-zni ha annyira fontos lenne.

Olyan helyeken ahol komoly folyamatokat visznek, orm layer, service layer, stb. van rá szükség. És mivel a php nem ragadt be a 4-nél igenis van ahol ezeket nem java-s szerverfarmokkal hanem php-vel oldják meg. Léteznek automatikus tesztelést, code coverage vizsgálatot, távoli debuggolást, és még jó rakat dolgot támogató kiterjesztések, és nem állt meg a világ a foreach-es echo-nál.

De ennek csak pici része a 'webfejlesztés', de van pl. komponensalapú eseményvezérelt megjelenítő keretrendszer is php-hez, ha valaki arra fanyalodik, szóval ott sem árt ha picit okosabb a nyelv.

--
hege

ez rém egyszerű: bárki ide leírja hogy szerinte miért nem jó a php5 általános képességeihez képest az általa használt OO modell, azonnal meaculpázva javítom a cikkben is ezt a mondatot.

a php egy szkriptnyelv, tehát gyengén típusos. az oo modell a java-1 modelljéhez hasonlít talán a legjobban, és van benne type hinting, aminek egyetlen hiányosságát érzem, hogy interface típusra nem lehet hintelni. mi az amit más nyelvek jobban tudnak? többszörös öröklés? generics? általában referencia szerinti értékadás?

--
hege

Nekem csak egy gondom van a php5 OO dologgal, hogy teljesen fölösleges, mivel scriptnyelv és nincsenek típusok. Ahogy én látom az OO nagy része arról szól, hogy hogyan tudunk elegánsan trükközni a típusokkal (mondjuk C++-ban). (inheritance, factory, smartpointers, polymorphism stb) Ezért bőven elég lett volna annyival kiterjeszteni a php4-es objektumokat, hogy legyenek hozzáférési szintek (private, public), szerintem.

Gondoltam nem írok hosszasan erről. De akkor legyen :)
A típusosságnak kb azért nincs értelme, mert olyan kényelmi funkciókat vesztesz el, mint pl a szabványos tárolók nyelvi szintű támogatása php esetében az array, amit akár hash tömbnek is használhatsz stb. A rugalmasságot veszíted el vele, ami szerintem a szkriptnyelvek megszületésének oka volt.
Az oo minden lehetőségét meg pont amiatt nem érdemes implementálni, mert szkriptnyelvből adódóan nincs szükség arra, hogy oo módszerekkel szivasd meg magadat. Ugyancsak példa erre a szabványos tároló. Vagy ahhoz hogy run-time történjen valami, nem kell szabványos interface-eket definiálni mint mondjuk so-ből objektumot importálásnál, mert minden futásidőben történik.
A másik elenérv pedig az, hogy az amúgy is lassú (relatíve persze) szkriptfuttatást még lassabá teszi az oo.
Szóval pont a típusmentesség, ami az igazi előnye a szkriptnyelveknek, tesszi fölöslegessé a szigorú objektum orientáltságot.

Nem ismerem sajnos a Pythont-t, biztos rengetek remek alkalmazást írtak benne, és biztos megvan a létjogosultsága. De nem tudom, hogy sebességben hogy teljesít mondjuk C++-al szemben, iletve mondjuk rugalmasság szempontjából a Perl-el szemben(bár ott is vannak típusok - ld. lentebb). Ha jól tudom, kódszépségben verhetetlen :)

Hát először is, eléggé típusos, még egy int-et se lehet megadni egy stringnek, nem konvertál default (ld. perl).
Eléggé objektum-orientált is, az alap változók is mind objektumok.

Sebesség: Nagyon gyors, ha yól van a progi megírva. A portage rendszer jelen pillanatban több mint 11000 csomagot kezel a rendszeren, és egy p3 1.5GHz <512 MB gépen a emerge -avuDN world kiszámtása (ez ~ apt-get dist-upgrade) olyan max 15-20 sec alatt megvan, ha leterhelt a gép.

Persze C-ben 1000x gyorsabb minden, de a C nem scriptnyelv, hanem minden egyéb.

Kódszépség: Hát differenciálisan ya. De azért ha valaki nagyon töri magát, ebbe is tud randa kódot írni. Bár az is csak a normális python kóddal összehasonlítva lesz randa.

mivel scriptnyelv és nincsenek típusok...

Tipus igen is van. Amugy nem tudnal osszeadni ket szamot, vagy meghivni az objektum egy metodusat. Gyengen tipusossag. Nem attol lesz egy nyelv kva jo nyelv, hogy minden helyre kiirod hogy int, char*, ...
Atlathatobb kesobb, az biztos.

Amugy ha szavazas, en a Ruby melle egy + :)

Jah, ebben igazad van; bár én a tipusnélküliséget abban az értelemben használtam, hogy sehova sem kell kiírni, hogy milyen is az a változó, illetve semmi megkötés nincs, hogy egy változó ha kezdetben ezt vagy azt tárolta akkor a későbbiekben hogyan működik. A C-t és a C++-t is gyengén típusosnak hívják (néhol meg erősen típusosnak :) ), ezért neveztem a php-t típus nélkülinek.
Mindig a felhasználási módtól függ egy nyelv hatékonysága, szerintem.

Szerintem nem véletlenül. Talán lehet hogy megnézték melyek a legelterjedtebb OO-t támogató nyelvek és megpróbáltak arra hasonlítani. Nekem a típusosság hiányzik itt-ott, OO-nál nem jön rosszul, és a type hinting amit lehet csinálni vele az nem elég erős. pl interface-re nem lehet kényszeríteni.

Persze az újfiúk (python, ruby) lehet hogy jobbak ezen a téren - nem ismerem őket testközelből, de hallottam már ilyen véleményt is.

--
hege

( mpathy | 2007. 07. 06., p – 08:53 )

A PHP-nek éppen az volt a nagy előnye, hogy egy iszonyú rugalmas taknyolónyelv volt, amit minden idióta könnyen megtanult. Ez az 5-ös verzióval megszűnt. Sikeresen elbonyolították, és "biztonsági rés" felkiáltással kiszedtek belőle nagyon jól használható, kényelmes fícsöröket.

--
- Hogyan lehet tanulni? - Jól kell tudni kérdezni. - Hogyan lehet jól kérdezni? - Ahhoz sokat kell tudni...

Nem csak az az egy előnye volt a Perl-hez képest, hogy könnyen tanulható, hanem az is, hogy nem kell újratanulnod a saját programodat 2-3 hónappal később. :)
Azért olyan dolgok nincsenek php-ban, hogy minden utasítás egy logikai értékkel tér vissza és ezért csak úgy simán lehet rövidzár operátorokkal a nagy semmi közepén ágaztatni a kódot, illetve az s/// sem ekvivalens a sqqq-val de ugyancsak nem egyenlő az s|||-vel, sem az s\\\-vel, sem az sttt-vel, és nem szopatja az embert olyannal, hogy @_ minden fgv-hez és még sorolhatnám.
De különben hogyan tudnának a Perl programozók sok lét leakasztani? :)

kiszedtek belőle nagyon jól használható, kényelmes fícsöröket.
Nem gondolod, hogy azok a fícsörök, amúgy meg megszokásból eredően jól használhatóak és kényelmesek?
Aki a PHP5-el kezd vagy könnyen tanulja meg a módosításokat, annak nem probléma a változás, ha másfelől meg van haszna is pl. biztonság.

Komoly munka $id helyett $_GET['id'] -t használni...

Ez pont olyan, mint a szabványos HTML kód... Elején kis odafigyelést igényel, aztán már megszokássá válik. Ha valaki erre is lusta, hogy kicsit odafigyeljen, az ne akarjon php-zni (se).

___
A backup olyan mint a sör. Egy backup nem backup, két backup fél backup, három backup egy backup. Egy backup nem backup...

Talán a globális form mezőváltozókra gondol, de azt a php5-ben is be lehet kapcsolni, ha valakinek nagyon hiányzik.
De ha tiltva van, akkor ki kell olvasni a mezőváltozót, mielőtt használod, tehát nem egy nagy kényelmetlenség, inkább tudatosítja azt, hogy ezek mező változók.

mert aztan olyan bonyolult dolog szimulalni a register_globals on-t
ajanlom figyelmedbe az extract fuggvenyt, ha mar mindenaron vissza akarod magad kuzdeni a kokorszakba.
csak ne sirj, ha veletlenul egy session valtozodat felulirtak egy get/post valtozoval. :S

Tyrael

Félig meddig igen, de az inkább csak bosszantó.

Inkább a tömbkezelés rugalmatlanná válására gondolok. Konkrét példát most nem tudok mondani, mert rég próbáltam, és órákba telne amíg újra utánajárnék, de a dinamikus bővítés körül buzeráltak meg valamit, hogy csak függvényel megy innentől, ami azelőtt egy változó értékadás szintű dolog volt.

--
- Hogyan lehet tanulni? - Jól kell tudni kérdezni. - Hogyan lehet jól kérdezni? - Ahhoz sokat kell tudni...

foreach valtozott, ha jol emlexem, 5tostol kezdve lehet objecteken is vegigiteralni, illetve 5ostol mukodik ez is: 


<?php
$arr = array(1, 2, 3, 4);
foreach ($arr as &$value) {
    $value = $value * 2;
}
// $arr is now array(2, 4, 6, 8)
?>

ezt regebben igy kellett volna: 


<?php
$arr = array(1, 2, 3, 4);
foreach ($arr as $key => $value) {
  $arr[$key] = $value*2;  
}
// $arr is now array(2, 4, 6, 8)
?>

tehat szerintem is rugalmatlanabb lett. :/

Tyrael

A php továbbra is egy iszonyú kényelmes taknyolónyelv, ezen felül egyre több komoly alkalmazás készül benne (nézz meg pl. egy symfony-t, meg fogsz lepődni), egyre több eszköz támogatja.

Bár gondolom neked ez nem mérvadó, de a következő verziójú Sun alkalmazásszerver natívan fog tudni php-t futtatni, és pont azért mert elég sok cégnél van most kritikus üzemben php oldal, amit nem dobnának ki csak azért hogy java-ra áttérjenek.

--
hege

most itt nem pistikézni kell, mert minden nyelven lehet rossz kódot csinálni, mindannyian követtünk el ilyet már nem is egyszer

de ezt _pont_arra_találták_ki_ hogy özönvíz előtti vagy/és fos libeket összetaknyoljon minimális nyelvi eszközkészlettel

most ebbe ilyen torzszülött gagyi oo-utánzatot (jóindulatúan) belehokizni további kifgyhatatlan lulzforrás

oké, nem egy eiffel. mégcsak nem is java.

Ezért írtam hogy 'normális'. Nem kiemelkedő, nem tökéletes, normális. A java-t én spec. jobban szeretem a típusosság miatt, de nem vészes a különbség.

Akár flamelhetünk is rajta, de szerintem nem érdemes. Ha szerinted design flaw-os, akkor indokold meg és értelmes emberek módjára megbeszéljük, hátha tanulok valami újat.

--
hege

Igen, tudom, hogy nem lehet, pont példa lett volna, hogy ez sincs normálisan megoldva, pedig időnként elég kényelmes lenne, mint @akarmi() or valami_hibakezelo(); helyett egy catch-l elkapni. Persze set_error_handler() -rel be lehet állítani egy saját függvényt, aztán azzal dobni az exceptionokat, de az milyen igénytelen már.

___
A backup olyan mint a sör. Egy backup nem backup, két backup fél backup, három backup egy backup. Egy backup nem backup...

( hubidubi | 2007. 07. 06., p – 09:02 )

Nemrég olvastam, hogy a Debian unstable/testingből is rövidesen ki fog kerülni a php4 támogatás.