PHP 5.3 i PHP6 deprecetated features
 

Danas sam instalira php 5.3 i primetio sam da ima dosta izmena. Ovo je lista svih funkcija i metoda koje su deprecated u 5.3 a većina toga će biti izbačena iz php 6 totalno.

(Za one koje mrzi da kliknu) nestaće:

Mislim da su to jako glupo smislili. Ne radi se o tome da li ću ja ili ti da upgade-ujemo u php 5.3 (ili 6) već šta se dešava sa postojećim LIVE sajtovima. Opet će da se napravi situacija kao kod prelaza sa php4 na php5 kada provajderi nisu hteli da stavljaju php5 jer pola sajtova ne bi radilo.

Recimo, sada ja imam sajt na na nekom serveru i provajder upgrade-uje na php6. I onda me cima klijent pa se zali da ne radi sajt a ja kazem "pa nisam nista menjao, nemoguće da ne radi". On u panici kuka "pa ... vidis da ne radi - uzmi i sredi - platili smo ti za to". A ti onda sedi i radi za dzabe jer su brainiacs smislili da poizbacuju gomile funkcija.

Pa upravo zato kod kvalitetnijih hosting provajdera postoji opcija izbora PHP verzije tako da klijent ili osobe zadužene za web sajt mogu da biraju koja verzija PHPa će "terati" njihov web sajt u bilo kom trenutku. S druge strane malo je verovatno da bi bilo koji ozbiljan provajder samoinicijativno uradio mandatorni upgrade na verziju softvera koja prethodno nije dovoljno dugo "odstajala" u repozitorijumima za trebljenje bubica čisto da bi bio u trendu i pratio modu. Zato mislim da migracija na 5.3 neće biti toliko bolna koliko se možda u ovom trenutku čini jer dok on dođe do statusa produkciono upotrebljivog PHP 6 će verovatno odavno zakucati na vrata. A i javna je tajna da PHP 5.3 nije ništa drugo nego prvi mačići "šestice".

Što se tiče izmena u 5.3 dovoljno je reći da su tolike da veći deo trenutnog gotovog softvera ne može da funkcioniše na njemu bez bar ponekog problema. Taj E_DEPRECATED je recimo napravio više štete nego koristi a u prvim buildovima navodno stabilne verzije bilo je problema da se uopšte isključi da se ne prijavljuje pa su recimo custom headeri pucali masovno. Veliki problem većini gotovih aplikacija je i to referenciranje funkcija što su dobro osetili na svojoj koži svi sistemi koji imaju implementiran neki vid hook sistema (Joomla, Drupal itd.) koji na taj način funkcioniše. Dosta problema se javilo i sa PHP framework sistemima koji žongliraju sa podrškom kako za "peticu" tako i za "četvorku" PHP-a (recimo CodeIgniter koji još uvek ima problema sa nekim bitnim stavkama zbog čega bi razvojni tim trebalo da porazmisli dokle želi da pruža podršku za PHP 4 u svom frameworku).

Da rezimiram. PHP 5.3 je u ovom trenutku, sudeći po reakcijama, stvar čiste mode. Sve što od novosti donosi jednostavno nije vredno da se uopšte razmišlja o njemu ni kao o test platformi a kamoli produkcionoj tako da bi buildovi iz 5.2.x game trebali još dugo da budu aktuelni kada su hostinzi u pitanju.

Iako si u pravu glede ovoga, ja moram priznati da mi je i malo drago zbog ovi funkcija i opcija koje su izbacili, jer kao sto se zna, radi o stvarima koje se pokazale kao loše rješenje (uglavnom u smislu sigurnosti i brzine).

Mnoge će se stvari rješiti putem search&replace opcije u editoru, a i vec dugo vremena na "svakom koraku" je pisalo da su preg_ brze od ereg, da treba biti iskljuceno register_global, magic_quotes_gpc, magic_quotes_runtime...

Ma daj blues, ajde priznaj da li si i jednu jedinu od ovih deprecated f-ja koristio u poslednje vreme?

Vec 100 godina najavljuju da ce u PHP6 izbaciti kontroverzni magic_quotes, ovo je kontam poslednja "veca" revizija pre PHP6 i logicno je da je proglase "deprecated" kako bi se ljudi navikli na to. Kome sajtovi ne rade bez toga sto rece neko, moci ce da "trche" na PHP5.x dok se to ne sredi.

Inace uz snow po defaultu dolazi PHP 5.3 tako da sam i ja vec presao na isti :)

a ja licno, sam odavno prestao da koristim sve stvari koje su oznacene sa depreciated... zlu ne trebalo :)

Ovo mi se desilo previše puta, i jedno vreme sam mislio da je to stvarno moja odgovornost, i želeći da ispoštujem klijenta, ispravljao sam kôd (besplatno). Problemi su bili u upgrade-ovanju servera sa PHP4->PHP5. Naravno sada mi to ne pada na pamet da radim. U ugovoru jasno preciziram da niko ne može neovlašteno da "čeprka" po projektu koji sam ja izradio, a to uključuje i samog klijenta koji ne može (ne sme) da direktno pristupa na recimo ftp/mysql, ne sme da menja direktno fajlove i sl., niti provajder sme da (bez pitanja) menja konfiguraciju servera (što se inače redovno dešava po jeftinim shared hostingzima) -- osim ako nije posebno drugačije navedeno. Odnosno u slučaju kada oni to ipak rade, garancija ne važi, pa su dalje slobodni da rade šta hoće, o svom trošku. Dakle ili sam ja "gazda" ili je neko treće lice, ali nikako nismo zajedno gazde.

Tu dolazimo do ovoga. Pametno je zakupiti ovakav hosting, gde će se moći instalirati verzija po izboru, kada mi to želimo.

I naravno klijenta treba u startu informisati spram koje verzije se radi projekat, šta to znači, koje su implikacije, šta se očekuje u budućnosti i zašto, tako da kada i ako dodje do upgrade-a servera, da ne bude iznenađenja tipa "platili smo, popravljaj za džabe".

Nije problem samo u tome da li je neko koristio ili nije, vec je problem u nasledjenim stvarima koje ima vecina programera a koje sada jednostavno rade pa nije bilo potrebe za izmenama

Pa pazi ovo, koji je OBJEKTIVAN razlog da se onemogući:

A možeš i dalje:
Prvo je deprecated, a drugo je sada ok? Zbog čega?

Slažem se da su te magic quotes samo pravile nepotrebnu zabunu i bile uzrok mnogih bug-ova, ali zašto izbaciti funkciju? Kada bi stavili da funkcija stoji samo ne radi ništa (jer je ionako izbačeno magic quotes) je daleko bolje za backward compatibility nego da kompletno izbace funkciju pa se generiše fatal error i puca script.

Dalje, globalno milijarde linija koda koriste "ereg" funkcije, šta ljudi da rade kada se to izbaci? Da menjaju sve svoje klase zbog toga? Kome će to da naplate?

Takođe sam puno koristio {} u stringovima, a šta sada da radim? Da pretražujem svuda gde sam to koristio da mi script ne bi pucao zbog gluposti.

Ja sam mislio da su ovi iz PHP nešto naučili u prethodnoj velikoj migraciji sa 4 na 5, ali oni sada prave još veće gluposti, i sve mi više liči na situaciju kada izigravaju Bogove "baš nas briga, tako je kako mi odlučimo, a ti ako nećeš da menjaš - neće ti raditi script".

Tako će i ovi što prave razne Joomle, CodeIgnitere i ostale slične stvari da totalno pošize od milijarde pitanja "od jednom mi se pojavljuje neka greška" ili "ne radi mi sajt" ili "prikazuje mi se prazna strana".

Što se tiče hosting provajdera, tu se na žalost najmanje pitaš ti. Prvo što retko imaš uticaja na izbor provajdera, a drugo što imaš još manje uticaja na njihove odluke.

Ipak mislim da ako neko hoće da pređe jednog dana na PHP6 neka skine ovaj 5.3 bar da vidi gde će imati problema.

Sticem utisak da ovo nisi skapirao. Ne radi se o iskljucenju "complex" sintakse (tipa "ovo je string sa varijablom {$var}" vec o tretiranju stringa kao niz (kao u C-u) tipa treci char je $string[2]. Ranije je za to moglo da se koristi $string{2} a sada je to deprecated.

Kao i za ereg(i) i kod ovoga jedan search/replace resava problem :)

I magic_quotes_runtime od verzije 5.3 spada u DEPRECATED kategoriju kao i sve što je na bilo koji način povezano za magic_quotes sistemom.
Još od kako se prvi put pojavio na PHP sceni za magic_quotes sistem je jasno stavljeno do znanja da je zbog kompatibilnosti sa starijim verzijama PHPa i potencijalnih problema sa konfiguracijama servera potrebno da kod bude u mogućnosti da funkcioniše i kada je magic_quoutes uključen i kada je isključen. Ja mislim da je to bila ubedljivo najčešće navođena napomena po raznim tutorijalima, kursevima i dokumentaciji. Ako prelazni period od pa sad već skoro više od 10 godina od kako se termin magic quotess prvi put pojavio (PHP v2) nije dovoljan da se neke loše programerske navike eliminišu onda zaista nemam komentara.
"Vitičaste" zagrade u PHP5.3 i dalje omogućavaju da string podaci u sebi sadrže blokove koji referenciraju promenjljive tipa "Nešto {$promenjljiva} još nešto" ali nije moguće više pristupati karakterima stringa putem vitičastih zagrada tipa $promenjljiva{8}.
Neće oni da šize nego korisnici tih sistema mada iskreno i bez novog PHPa nisu se nešto proslavili :)
Ovo je sada već pre svega pitanje ozbiljnosti naručioca posla jer ako se već na samom početku škrtari na kvalitetnom hostingu mislim da je pametnije celu stvar odmah na početku saseći i sačuvati živce. A ozbiljni hosting provajderi itekako vode računa o softverskoj sceni i potencijalnim problemima koji mogu da se jave sa softverom njihovih klijenata. Čak i da se kasnije tokom eksploatacije stvori neki problem izazvan svojevoljom provajdera postoji jedna jako efikasna pravna zaštita od maltretiranja klijenta a to je navođenje tačnih tehničkih specifikacija eksploatacionog okruženja. Odgovarati za samovolju hosting provajdera koji je samoinicijativno instalirao problematičnu verziju PHPa uprkos tehničkoj specifikaciji bi bilo otprilike isto kao kada bi neko sada tužio razvojni tim zato što je udario grom u hosting server na kome se nalazi sajt :)

Usput evo jednog interesantnog dokumenta za one koje zanima šta je to novo što PHP 5.3 (realno i PHP "šestica") zaista donosi sa sobom.

http://conf.phpquebec.com/slides/200...uebec_2009.pdf

Jel' vas dvojica mene nešto palite ili šta? :D

A onda i mister holodoc:

'ajde? :) Pa o tome i pričam, od jednom promene sintaksu i ne možeš da pročitaš određeni karakter stringa sa {N} već sa [N]... i to je kao ok u verziji većoj od 0.1 beta promeniti sintaksu jezika? I kada to ostane - ide parse error i pukne script.

I onda dinketovo rešenje je:
^ Zbog takvog predloga sam siguran da me u stvari zajebavaš :). To možda i prođe kada imaš 1 ili 2 sajta. Šta da radim sa ostalim sajtovima? Da menjam jedan po jedan narednih 6 meseci?

Velika je razlika između "depricated" i "parse error", a to drugo će upravo da se desi kada izbace to što su rekli. Za ovo prvo može da se isključi notice, a zbog ovog drugog ti ne radi script. Ne znam da li me razumete? Svi scriptovi u kojima ostanu funkcije koje su ovi odlučili da izbrišu, ili "nepostojeća sintaksa", će generisati error - ne rade - kraj! Nije više ni u pitanju da li ti smeta E_NOTICE ili bilo šta - script se i ne izvrši.

^Za Beano kazes lepo adminima da ne stavljaju nista novije od PHP 5.3 i resen problem (pod uslovom da te poslusaju, meni uredno trchi neki mysql 5.1 preview na production masini, bez komentara).

Sto se sajtova ostalih klijenata tice, mozda je stvarno vreme da pocnes da potpisujes ugovor da taj i taj sajt garantovano radi za tu i tu verziju PHP-a, apache-a, mysql-a bla bla bla ... i da odrzavanje (sto ce reci izmedju ostalog i update koda u ovakvim slucajevima kada je narusen backward compability) naplacujes posebno.

Da, slažem se da to može da šljaka u takvom "idiličnom" okruženju (mada se i tamo dešava da neko instalira nešto 'nako... da proba), ali postojao je život i pre i posle Beano :)

Iskreno ni ne sećam se kada sam poslednji put video kod koji tako manipuliše sa stringovima tako da što se mene lično tiče ovo i nije nešto što će mi nedostajati.

S druge strane PHP vuče sintaksičke korene iz C-a u kome se elementima stringa (karakterima) pristupa uglastim zagradama a[0], a[1] tako da ne vidim razlog zbog čega je uopšte i uvedena ova alternativna sintaksa sa vitičastim zagradama osim da se nastavi tradicija PHPa da omogućava previše različitih načina da se jedna ista stvar odradi i tako stvori dodatni prostor za greške.

Molim te, daj mi primer kako ti "izvlačiš" recimo 3 karakter iz nekog stringa. Stvarno me interesuje koje je to bolje i preglednije rešenje.

I da, kada sam ja prvi put pokušao tako nešto, i ja sam probao sa $string[N], očekujući da je ista sintaksa kao u C, međutim ako su već uveli nešto (koliko god se [ne]slagali sa tim) što se vuče jako dugo, kako mogu tek tako da odluče da to izbace od sledeće verzije.

Potpisujem da je u ranijim verzijama manuala stajalo samo $string{2} tj. u dokumentaciji je stajalo da je obavezno koriscene viticastih zagrada za pristup x-tom elementu niza a ne (kao u C-u) uglastih.

E sad da li je to i ranije radilo i sa uglastim i sa viticastim pre nego se neko setio da to i dokumentuje - ne bih znao.

@bluesman
Fakat najjednostavniji nacin da izvuces n-ti element u stringu je bas ovaj pristup :)

sto se tice {} vs [] sintaxe za pristupanje pojedinacnim karakterima stringa, ja mogu da potpisem da je u predhodnim verzijama manuala (pre nego sto je 5.3 i zapocet) pisalo da {} sintaxa nije preporucljiva i da treba koristiti [].

ja se php-om bavim od verzije 5 (mada sam bio prinudjen i da pisem php4-compatible kod) i nikada nisam koristio {} vec bas []...

a sto se samog PHP 5.3 tj PHP 6 tice meni se neke "novotarije" bas svidjaju (closures.. hell yea!), dok su mi neke mnooogo lose uradjenje (tipa / u nejmspejsima!?!?! to mi toliko izgleda neprirodno i ruzno da nemam reci... mogli su lepo da koriste . ili eventualno : ako im je . previse tesko za implementaciju - a svaki context-aware parser/kompajler bi bez problema mogao u ovakvoj situaciji da podrzi tacku kao delimiter)...

i thumbs up za sve deprecated fje! (mada se slazem da je mnogo bolje ostaviti fju koja ne radi nista nego dizati E_DEPRECATED, ali sa function_exists lako moze da se 90% koda koji koristi te fje natera da igra po pravilima sestice...)

Pretpostavljam da ovde misliš na pristup "trećem" karakteru ali u svakom slučaju dotaći ću i varijantu "izvlačenja" dela stringa.

Dakle, ako bih ikada bio u situaciji da moram da pristupim sadržaju određenog indeksa stringa u PHPu onda bih sigurno koristio sintaksu sa uglastim zagradama $string[index] ne zato što teram inat ili što je ona možda bolja i preglednija već zato što je svakako logičnija, tradicionalnija i ustaljenija varijanta od "vitičaste" alternative. Drugim rečima svako ko se ikada dotakao bilo kog programskog jezika koji podržava manipulaciju stringova kroz nizove zna da se indeksima stringa pristupa korišćenjem uglastih zagrada. To što PHP podržava i ovu alternativnu sintaksu je jedna od njegovih specifičnosti koja verovatno nikada nije trebala da ugleda svetlost dana ali valjda je postalo jasno do sada da je PHP tehnologija za koju važi pravilo da nove i specifične stvari i ne moraju nužno da budu bolje :)

Što se tiče "izvlačenja" dela stringa tu verovatno ne bi trebalo da bude nekakve nedoumice. PHP je bar takav da je velika verovatnoća da za sve što može da se reši jezičkim konstruktima postoji i odgovarajuća funkcija. U konkretnom primeru substr bi trebalo da bude dovoljno dobro rešenje.
Nažalost ovaj deo oko "razlike u sintaksi sa C jezikom" nisam baš razumeo :1018: Sledeća dva primera rade potpuno istu stvar a jedina realna razlika koju ja vidim u njima su čisto vezane za sintaksičke razlike u jezicima.
Da rezimiram. "Vitičasta sintaksa", posebno njen kompleksni oblik, je po meni bila i još uvek jeste potpuno nepotrebna stvar u PHPu i iskreno mogu da kažem da mi se odluka o tome da otpadne u "kastriranoj" 5.3 verziji čini kao potpuno pozitivna stvar. Ono gde ljudi očigledno greše kada kažu da je to potpuno neprihvatljivo zbog kompatibilnosti sa postojećim kodom je što PHP 5.3 smatraju logičnim nastavkom 5.x game što jednostavno nije tačno. PHP 5.3 je čista "izvidnica" novoj "šestici" i kao takvog ga treba i posmatrati a siguran sam da dok nova verzija ne ugleda svetlost dana da će bar još koja velika revizija "petice" da izađe.

Inače svako može da učestvuje u davanju predloga vezanih za nove verzije i revizije PHPa putem ogromnih mailing lista na matičnom sajtu a ono što danas nosi naziv "PHP 5.3" verovali ili ne je uglavnom plod diskusije i smerova na koje je sama zajednica najviše uticala :)

Nažalost koliko god PHP manual bio koristan opšte je poznato da on nije baš bez grešaka pa se često dešavalo da se neke stvari potpuno pogrešno dokumentuju. Da li je to bio slučaj i sa ovim primerom ne bih znao ali kompleksna "vitičasta" sintaksa je uvedena u PHP 4 dok recimo klasično indeksiranje stringova ako me pamćenje ne vara postoji još od PHP verzije 2 (naravno one "prepisane" savremenije).

Mister, prvo da ti kažem da mi se čini da ti samo "preletiš" preko onoga što napišem, ne pročitaš šta sam napisao nego požuriš da daš odgovor. Zatim, kada pričamo o nekim primerima, računam da nisi počeo da pišeš php kod prekjuče već da imaš iskustva i od ranije. Ima na ovom forumu dosta ljudi koji pišu php bar 10 godina i imaju gomilu napisanog koda, a vi konstatno insistirate da su od "pre nekoliko meseci preporučili ovo-ono". To je ok samo za ljude koji su počeli pre nekoliko meseci, a drugima pravi problem sa starim sajtovima.

Kada napišem:

To znači "kada sam pokušao prvi put pre 10-11 godina u php 3, očekivao sam da je sintaksa kao u C - ali NIJE, pa sam bio prinuđen da koristim {} umesto [].

Dakle, ranije je $string[4] generisao error, pa si morao da koristiš $string{4}. To je bilo totalno nelogično i tu nema dileme. Pa radiš tako godinama i onda od jednom izbace tu sintaksu, sada više ne može {} nego mora [] (kako je od početka i trebalo da bude). Pa kada su već napravili zabunu od početka, najmanje što mogu da urade je da (zbog ljudi koji su počeli da rade u php mnogo pre verzije 5.3) ostave da radi i jedno i drugo.

Nadam se da je sada jasnije zašto se bunim?

PHP 2??? Pretpostavljam da mislis na PHP/FI?

http://www.php.net/manual/en/history.php.php

Ajd da se ne foliramo ovde, sumnjam da je bilo ko sa ovih prostora radio ista ozbiljno pre verzije 3.0 (ja sam istu ukacio 2000-te ali sam ozbiljno programiranje u PHP-u poceo bas u trenucima kada se pojavio PHP4).

Inace ne mogu da kazem da sam isprobavao $foo[x] ali u manualu je jasno bilo navedeno da se koristi viticasta zagrada. Uostalom evo i dokaza iz Web Archive (PHP manual iz 2003 godine) :)

http://web.archive.org/web/200304011...pes.string.php

Hvala dinketu na trudu, ja bih samo iskoristio ovo što je pronašao da dodam u prilog neozbiljnosti. Obratite pažnju na ovu rečenicu:

Na stranu to što sam siguran da mi je generisao error kada sam probao sa "array braces", koliko je ovo neozbiljno? Znači u verziiji 4 su stavili da je "depricated" [] i preporučuju {}, da bi u verziji 5.3+ uradili upravo obrnuto.

To nije prvi put niti jedini slučaj da "lutaju", čak i njihove implementacije ostaju baš to "njihove" a ne "standardne", tako imamo pomepzne najave nekih "features", ali je implementacija delimična i nepotpuna, ili što je još gore "specifična" (njihova vezija).

Ne znam zbog čega imaš takav utisak ali odgovorno tvrdim da ne "prelećem" preko postova, čak štaviše dosta vodim računa o detaljima koje sagovornici iznose pa je često to razlog nesporazuma :) Isto tako da dodam da niti sam sujetna osoba niti imam nameru da bilo koga ovde diskreditujem već jednostavno, bar ja mislim da je tako, pokušavam da vodim argumentovanu raspravu.
Uz svo dužno poštovanje ali sa ovime nažalost ne mogu da se složim jer jednostavno nije tačno :) Doduše možda se u trenutku testiranja koda radilo o nekoj bagovitoj reviziji PHPa koja nije radila kako treba pa su se otuda javile greške. PHP 3 kao i PHP 2 u potpunosti podržavaju sintaksu "uglastih" zagrada koja omogućava da se indeksima stringa pristupi recimo ovako $string[index].

Pošto zaista ne volim da bilo šta tvrdim bez argumenata nisam bio lenj pa sam napravio mali test i na brzinu instalirao PHP 3.0.17 na jednom od računara i propustio kroz njega onu istu skriptu od malopre. Kao što se može videti na priloženoj slici PHP nije prijavio apsolutno nijednu jedinu grešku a skript se uspešno izvršio. Apsolutno sam siguran da bi test bio uspešan i sa starijim revizijama "trojke" pa čak i sa "dvojkom" ali nažalost to sada ne mogu da demonstriram jer je za instalaciju "dvojke" potrebno malo previše muke :)

Za one koji možda misle da sam na bilo koj inačin namestio rezultate mogu slobodno preuzeti bilo koju verziju "trojke" PHPa sa sledeće adrese jer nažalost matični sajt od pre par meseci više ne nudi download starih verzija PHPa :(

http://www.oldapps.com/old_version_php.php



Pa da... Zvanični naziv je tada bio PHP/FI 2.0 ali skoro svi tu verziju jednostavno zovu "dvojka" :) Što se tiče mojih početaka iako nisam pristalica "čiji je duži" sindorma napomenuću da naravno da nikada nisam koristio "dvojku" za bilo šta smisleno osim za eksperimente. Moj prvi kontakt sa PHPom je bio sada već davne 1999. godine sa tadašnjom "ganc taze" verzijom 3.0.12. Doduše, PHP nije postao moj jedini programski jezik, ni tada a ni sada, tako da sam tek kasnije počeo da eksperimentišem sa raznim verzijama koje su bile dostupne u arhivi matičnog sajta koja nažalost više ne postoji :(

Nažalost izmena poruke očigledno ne radi tako da moram da postujem u novom postu. Malopre sam pogrešio i link ka starijim buildovima PHPa u stvari još uvek postoji.

http://museum.php.net/

Doduše većinu stvari u njemu je potrebno prethodno buildovati ali to ne bi trebalo da bude neki problem.

^Dakle tvoj je veci al samo za par mm ;)

Da se vratimo na temu, ja nemam potrebu da proveravam da li radi jer kao sto sam u ranijim postovima i rekao nikada nisam ni isprobavao tu (tada) "deprecated" sintaksu, vec sam se drzao manuala. E sad ova nekonzistentnost u razvoju PHP-a bila bi vredna jednog Blog posta na temu, ali nedelja je vece tako da ... :)

Mister, ne mislim da želiš da me "diskredituješ", da je tako ne bi ni diskutovali. Šta više, totalno mi je nevažno čak i da to pokušavaš. Ja samo kažem da ne čitaš pažljivo šta sam napisao, već 2 puta prepričavaš moj post i daješ mi nepotrebna dodatna objašnjenja odvlačiš priču na neku stranu koja nije ni sporna.

A što se tiče "tačno / netačno" ja ti opet kažem da prvi put kada sam probao $string[N] dobio sam error, koja je to verzija bila - nemam pojma, ali sam od tada koristio $string{N}. Bilo kako bilo, opet pričamo o detaljima a suština je daleko važnija: ne možeš (bez velike arogancije) tako lako da "obrišeš" nešto iz sistema koji postoji godinama i kojeg koriste "milijarde" programera ('ajmo cepidlake, rekao sam "ključnu reč" :))

Zbog ovakvih situacija je i izmišljen termin: backward compatibility. Odlično što unapređuješ sistem, ali hajde napravi da i ono postojeće ne postane neupotrebljivo. Šta su oni uradili? Dodali su specijalan E_NOTICE koji su nazvali E_DEPRICATED čisto da te obaveste da će u sledećoj verziji to da postane E_PARSE_ERROR i da ti neće raditi script. To nije backward compatibility.

Bila bi ključna da ima i jedno PHP između "milijarde" i "programera" ;)
To nije problem specifičan samo za PHP. Čak štaviše PHP je i dobar po tom pitanju. Primera radi iskusniji Java programeri verovatno imaju da ispričaju pokoju interesantnu priču o tome kakva je bila tranzicija sa JDK1.4 na JDK1.5 i zašto nijedna ozbiljna kompanija koja se danas bavi razvojem softvera baziranog na Javi ni ne pomišlja da se u potpunosti prebaci na JDK1.6. Probajte njima da objasnite šta je "backward compatibility" ;)

Tako je i sa PHP-om. Stvari se jednostavno menjaju i one koje su da se ne lažemo odavno trn u oku se polako uklanjaju u novijim verzijama. Ključne prelomne tačke su poznate. Za PHP 4 to je bio PHP 4.3 a za "peticu" njen prvi "stabilan" build (ko se seća ovog perioda zna o čemu pričam) dok "šestica" bukvalno nastupa na scenu sa PHP verzijom 5.3. To što se pojavila nova verzija koja nije u potpunosti kompatibilna sa starijom nije ništa novo i ne treba da bude povod za paniku jer ponavljam još jednom svaki ozbiljan provajder imaće razumne tranziocione periode u toku kojih će u svojoj ponudi imati mogućnost izbora PHP verzije. Primera radi podrška za PHP 4 već odavno više ne postoji ali svi kvalitetniji hosting provajderi i dalje nude podršku za poslednju stabilnu verziju "četvroke" (PHP 4.4.8) U suprotnom već na samom početku nemamo šta da pričamo o ozbiljnosti klijenta i provajdera.

Na kraju krajeva ako nekome i za 20 godina bude bilo potrebno da koristi softver koji zahteva PHP 4 šta ga sprečava da iznajmi jedan dedicated server i da na njemu instalira šta hoće? Ne treba da pominjem da ako ta matora aplikacija toliko vredi da se više isplati pokrivati troškove infrastrukture nego napisati novu ili čak prepraviti staru aplikaciju da će sigurno moći da pokrije troškove jednog iznajmljenog linka i jednog (ili više) Unix/Linux baziranog servera ;)

Kod mene na poslu je, baš na moje insistiranje, jedna osrednje velika aplikacija (JSP front-end sa, dosta web servisa, te nekoliko proksija za .NET servise) prebačena sa Jave 1.4 na 1.5, nikakvih problema nije bilo. Istim prilikom je i TomCat prevučen na verziju 5, jedino što nismo smeli da diramo jeste MySQL. Ni pod razno.

Ne kažem da neko nije imao problema, ali mi zaista nismo imali ni najmanjih problema kada smo to radili. Za 1.6 ne znam.

eregi npr nece nestati vec ce biti premesten u pecl kao i jos dosta od navedenih fja.

Znaš kako, bilo je nekih problema pri prelasku sa 1.4 na 1.5 ali su svi oni posledica uvođenja novih stvari (tipa enum keyword), a nikako izbacivanja postojećih. O prelasku na 1.6 da i ne pričamo, tek tu nije bilo problema ... Upravo je backward compatability razlog zašto se Java tako sporo menja (i predstavlja razlog nezadovoljstva dela korisnika), jednostavno ne mogu sebi da dozvole da kažu "izbacujemo ovo, od sutra ne važi". Stavi da je nešto deprecated i furaj, edukuj korisnike da je nešto loša praksa, ali nemoj misliti da će neko biti oduševljen sa idejom mora da menja milione linija koda.