-
Aceasta este o retrospectiva a ultimului an.
In caz ca inca se mai intreba cineva, nu, PHP 6 nu a aparut si nici nu va aparea prea curand, probabil.
De ce este relevant? De cand am inceput acest blog am avut la final de an un post legat de PHP 6 si faptul ca acesta nu a fost lansat. In 2008 era o intrebare populara, dar nimeni nu mai crede asta acum, asa ca voi incheia acest subiect acum. Sa revenim la anul care s-a incheiat.
Aproape de jumatatea anului a fost lansata versiunea PHP 5.5, aceasta aducand in plus functionalitati cum ar fi: finally , generators si multe alte inbunatatiri.
Ca in 5.4, nu sunt functionalitati definitorii pentru limbaj. In aceasta noua versiune chiar sunt lucruri care pot fi inlocuite cu usurinta, dar daca sunt prezente, sunt bine venite.
Chiar daca PHP da dovada de multa dinamica in ultima vreme, cred ca in acest an cuvintele cheie au fost HTML5 si JavaScript.
HTML5 are parte de multe imbunatatiri, iar componente mai vechi incep sa creasca in popularitate. Firmele incep sa investeasca in jocuri care functioneaza in browser folosing WebGL. Chiar si jocuri mai vechi sunt portate catre platforma, folosind tehnologii cum ar fi asm.js.
Si, pentru ca am vorbit de jocuri, mi se pare foarte interesant cum doar acum 5-7 ani jocurile bazate pe JavaScript erau destul de simpliste, iar acum sunt comparabile cu cele de pe PC sau console.
Cred ca revolutia web, pe care multi o asteptau, incepe sa prinda avant. In sfarsit Web-ul este o platforma in adevaratul sens al cuvantului si JavaScript un limbaj cu adevarat apreciat.
Succesul se datoreaza tuturor partilor, nu mai este vorba doar de ECMA sau doar de producatorii de browsere, acum este o adevarat dinamica. Revolutia Web este in plina desfasurare!
Cand vine vorba de backend, lumina reflectoarelor a fost asupra Node.js. Acesta incepe sa devina un jucator important. Au aparut frameworkuri noi si nu mai este o platforma folosita predominant de hackeri dornici sa exploreze tehnologii noi, ci si de companii mari, cum ar fi PayPal, LinkedIn si Yahoo, oferind un vot de incredere pentru acesta. Cred ca Node.js incepe sa-si gaseasca locul si o nisa de piata, iar eu, un fan JavaScript, nu pot sa fiu decat incantat.
Un avantaj al Node.js este ca nu trebuie sa ai grija mai multor versiuni de JavaScript, asa cum este necesar in browser. Asta permite folosirea ultimelor facilitati ECMA in mod liber, un mediu in care poti dezvolta JavaScript fara dureri de cap.
Tehnologic vorbind, a fost un an foarte interesant pentru web development.
In final, va doresc tuturor un 2014 extraordinar de bun!
-
Notiunea de closure in PHP, desi a aparut in PHP 5.3, a fost realizata intr-un mod adecvat abia in 5.4, asa cum am mai spus-o si pe blogul meu.
Wikipedia ne spune:
In computer science, a closure (also lexical closure or function closure) is a function or reference to a function together with a referencing environment—a table storing a reference to each of the non-local variables (also called free variables) of that function.
In PHP nu este un concept foarte popular sau foarte cunoscut. De multe ori acesta este confundat cu Anonymous Functions. In limbajele functionale totusi, acest concept este foarte popular, pentru ca acolo este cu adevarat nevoie de el!
Scheme
Cand Brendan Eich a conceput JavaScript, s-a bazat pe limbajul Scheme si a ajuns sa faca o implementare a acestuia cu o sintaxa de C. Sintaxa C era si este in continuare mult mai populara, iar atunci (1995) limbajul Java era foarte “la moda”.
Sintaxa Scheme este similara cu sintaxa Lisp, in sensul ca se folosesc paranteze in jurul expresiilor pentru a le rula. Operatorii sunt definiti ca si functii si la fel ca o si in cazul functiilor, se pun in partea stanga a parantezei.
Sa luam un exemplu de closure in Scheme:
1(define (make-counter) 2 (let ((count (begin 3 (display "run parent function and return 0") 4 ))) 5 (lambda () 6 (set! count (+ count 1)) 7 (begin 8 (display "inside child function ") 9 count))))
Functia principala seteaza o variabila “count”, cu valoarea 0 si afisaza “run parent function and return 0”, apoi intoarce o alta functie lambda, care incrementeaza variabila definita in functia principala si apoi afisaza “inside child function”.
Functia rezultata din executia functiei principale o stochez intr-o variabila pentru a o putea rula ulterior de mai multe ori:
1> (define counter (make-counter)) 2run parent function and return 0 3> (counter) 4inside child function 1 5> (counter) 6inside child function 2
Cu alte cuvinte, de fiecare data cand apelez (make-couter), acesta va intoarce o functie noua care are acces la mediul in care a fost creata. Daca pare ciudat din pricina sintaxei, promit ca in JavaScript va parea mult mai natural.
Acest concept este foarte interesant pentru incapsulare. Mediul la tipul cand functia parinte este executata se poate incapsula, iar ulterior se va folosi de accest mediu fara grija ca acesta se poate schimba din cauze exterioare.
Pentru limbajele functionale acesta este un concept foarte interesant. Cand vine vorba de limbaje obiectuale totusi, conceptul aproape inutil, pentru ca obiectele au si ele rolul de incapsulare.
JavaScript
JavaScript a fost de la inceput un hibrid, un limbaj functional, orientat obiect, cu mostenire bazata pe prototype. Iar daca acestea nu erau suficiente, sintaxa a fost preluata din Java (C).
JavaScript nu a mostenit multe de la Scheme, dar a mostenit conceptul de closure.
Un motiv pentru care era nevoie de closure in Scheme este acela ca daca o functie nu gaseste o variabila in mediul in care se afla, o va cauta in mediul superior. Sa luam un exemplu:
1(define x 1) 2(define (add-in-env y) (+ x y))
Daca apelam add-in-env cu 2:
1(add-in-env 2) -> 3
Pare la fel de ambiguu ca si in JavaScript, dar nu este tocmai asa. In Scheme sa faci mutatie nu e la fel de usor, simplu si transparent, deci o operatie ulterioara de:
1(define x 2)
va rezulta intr-o eroare.
In JavaScript a rezultat un hibrid. Mutatia este permisa, dar notiunea de a cauta o variabila in mediul in care te afli a ramas:
1var x = 1; 2var add_in_env = function (y) { 3 return x + y; 4} 5 6add_in_env(2); // rezulta 3
Pana aici e ok, dar pentru:
1x = 2; 2add_in_env(2); // rezulta 4
In acest caz, lucrurile scapa foarte usor de sub control.
Dar, ca sa rezolvam problema, putem pur si simplu sa definim variabila in mediul care isi va termina executia (se va inchide = will close):
1var make_counter = function () { 2 console.log("run parent function and set counter to 0") 3 var count = 0; 4 5 return function () { 6 count = count + 1; 7 console.log("inside child function"); 8 return count; 9 } 10} 11 12var counter = make_counter(); 13console.log(counter()); 14console.log(counter()); 15 16var counter2 = make_counter(); 17console.log(counter2()); 18console.log(counter()); 19console.log(counter2());
Outputul va fi:
1run parent function and set counter to 0 2inside child function 31 4inside child function 52 6run parent function and set counter to 0 7inside child function 81 9inside child function 103 11inside child function 122
Chiar daca functia principala si-a terminat executia, mediul din interiorul ei este pastrat ca un closure pentru functia care a fost intoarsa. Doar in momentul in care si subfunctia nu mai are referinte catre ea memoria alocata pentru closure va fi dezalocata.
Chiar daca JavaScript are obiecte, acestea nu au metode private. O abordare este sa pui un “_” (underscore) in fata numelui functiei si sa o consideri privata. Din punctul meu de vedere asta este ca si cum ii rogi pe cei care vin dupa tine sa o considere o functie privata. Evident acest lucru nu este tocmai consistent.
Sa luam un exemplu:
1var obj = { 2 _secretFunction : function (key) { console.log(‘do secret ’ + key) }, 3 doStuff : function (key) { this._secretFunction(key) } 4} 5 6obj.doStuff(‘stuff’); // do secret stuff
Aparent avem o metoda publica “doStuff” si una privata “_secretFunction”. Totusi nu poti preveni un utilizator sa apeleze “_secretFunction”, sau mai rau, sa o modifice:
1obj._secretFunction = function (key) { console.log('new secret ' + key); } 2 3obj.doStuff('stuff'); // new secret stuff
Daca vrem ca functia sa fie ascunsa, iar acest lucru sa fie evident pentru toata lumea, din nou putem folosi un closure:
1var obj = (function () { 2 var secretFunction = function (key) { console.log(‘do secret ’ + key) } 3 4 return { 5 doStuff : function (key) { 6 secretFunction(key) 7 } 8 } 9})(); 10 11obj.doStuff(‘stuff’); // do secret stuff
Pentru ca functia parinte se va executa la inceput, practic spatiul in care a fost definit secretFunction si-a terminat deja executia, incapsuland logica. Obiectul intors poate sa apeleze functia pentru ca este definit in acelasi mediu ca si obiectul.
Pare complicat prima data, dar de fapt este foarte simplu cand intelegi conceptul.
Si apoi a fost… PHP
PHP inglobeaza multe optiuni diferite. PHP s-a dezvoltat initial ca un framework Perl, ulterior engine-ul fiind scris in C.
PHP este un limbaj dinamic care inglobeaza foarte multe concepte, de la obiecte, interfete si functii anonime, pana la goto labels. Nu este foarte clara directia in care ar trebui sa se dezolte limbajul, mai degraba ofera posibilitatea pentru abordari diferite.
In istoria ciudata a PHP, undeva in versiunea 4 a fost introdusa o sintaxa pentru Anonymous Functions, dar abia in PHP 5.3 a aparut o versiune mai “normala“.
Tot in versiunea 5.3 a fost introdusa si prima varianta de closures:
1$scalar = 5; 2 3$closure = function () use ($scalar) { 4 return 'Scalar: ' . $scalar . PHP_EOL; 5}; 6 7echo $closure(); // Scalar: 5 8 9$scalar = 7; 10 11echo $closure(); // Scalar: 5
Versiunea functioneaza in mare parte, dar trebuie sa specifici ce vei trimite catre closure.
Si mai exista cateva inconveniente:
1<?php 2class Foo { 3 private function privateMethod() { 4 return 'Inside private method'; 5 } 6 7 public function bar() { 8 $obj = $this; 9 return function () use ($obj) { 10 return $obj->privateMethod(); 11 }; 12 } 13} 14 15$obj = new Foo(); 16$closure = $obj->bar(); 17echo $closure(); 18 19Fatal error: Call to private method Foo::privateMethod() from context '' in [...][...] on line 10
Nu functioneaza pentru ca nu poti trimite $this ca parametru la closure, iar daca faci artificiul de mai sus tot nu vei putea accesa metodele private. Nu uitati, asta se intampla in PHP 5.3.
Ideea de a introduce acest tip de closure mi se pare bizara. Nu este prima daca cand in PHP se introduce un feature “bizar”, dupa cum vorbeam mai sus si de Anonymous Function. Pare work in progress.
Cred ca toata lumea se astepta ca acest feature sa functioneze la fel ca in JavaScript. Cred ca doar datorita JavaScript conceptul de closure a devenit atat de popular.
In versiunea PHP 5.4 lucrurile s-au mai schimbat, avem in sfarsit closures asa cum ne asteptam:
1class Foo { 2 private function privateMethod() { 3 return 'Inside private method'; 4 } 5 6 public function bar() { 7 return function () { 8 return $this->privateMethod(); 9 }; 10 } 11} 12 13$obj = new Foo(); 14$closure = $obj->bar(); 15echo $closure(); // Inside private method
Functioneaza!
Poti chiar sa spui:
1unset($obj); 2echo $closure();
si va functiona, pentru ca obiectul in interiorul caruia a fost definit closure-ul a ramas in memorie pana cand se va termina executia scriptului, sau se va apela:
1unset($closure);
Pentru mai multe detalii despre cum functioneaza closure in PHP 5.4, puteti citi acest blog.
-
PHP 5.4 a fost lansat!
Chiar daca acuma este yesterday news… literalmente, ieri 1 martie a fost lansat.
Lista de schimbari este disponibila pe php.net.
Ce regret este ca nici in aceasta versiune nu exista scalar type hinting. Singura modificare la type hinting a fost adaugarea cuvantului “callable”, despre care am mai vorbit cand a fost vorba de closures in PHP 5.4.
Un alt lucru interesant este ca de data asta chiar au fost scoase register_globals si magic_quotes_gpc, deci vechile aplicatii de PHP 4 nu mai au posibilitatea de a deveni compatibile cu ajutorul unor setari in php.ini.
De asemenea a fost adaugata functia hex2bin(), evident nu este foarte importanta,dar este interesant ca bin2hex() exista de la PHP 4. 🙂
-
Notiunea de Closure, a fost introdusa in PHP 5.3, o data cu o noua sintaxa, “mai traditionala” pentru functiile anonime.
PHP 5.3
In 5.3, un closure se baza pe termenul “use”, care transmite anumite variabile functiei anonime, transformand-o intr-un closure.
Problema este ca functia anonima nu va avea acces decat la variabilele trimise folosind “use”. In cazul obiectelor ele sunt trimise prin referinta, dar in cazul variabilelor scalare (int, string, etc.) acestea se transmit prin valoare, asa cum face implicit in PHP 5+:
1$scalar = 5; 2 3$closure = function () use ($scalar) { 4 return 'Scalar: ' . $scalar . PHP_EOL; 5}; 6 7echo $closure(); // Scalar: 5 8 9$scalar = 7; 10 11echo $closure(); // Scalar: 5
O alta problema este ca nu se pot trimite $this in cadrul obiectelor, deci doar proprietatile sau metodele care sunt publice nu pot fi accesate de closure.
PHP 5.4
In PHP 5.4 folosirea cuvantului “use” este optionala, iar tot mediul in care functia anonima a fost creata este disponibil in interiorul functiei.
Avantajul este ca atunci cand functia anonima este generata in interiorul unei alte functii, sau a unei metode, functia anonima va putea accesa mediul in care aceasta a fost creata chiar si dupa terminarea executiei acestuia. Obiectele din mediul creat se vor dezaloca de abea dupa ce se ultima referinta catre closure se va sterge:
1class testClass { 2 3 private $changeableVar = 1; 4 private $bigVar; 5 6 public function __construct() { 7 // Allocate a big variable so we can see the changes in memory 8 $this->bigVar = str_repeat("BigWord", 5000); 9 } 10 11 /** 12 * O metoda care intoarce un closure 13 */ 14 public function closure() { 15 16 return function () { 17 // Display the value of a private property of the object 18 echo 'Private property: ' . $this->changeableVar.PHP_EOL; 19 20 // Change the value of a private property of the object 21 $this->changeableVar = 2; 22 }; 23 } 24 25 /** 26 * O metoda care afisaza o variabila privata 27 */ 28 public function showChangeableVar() { 29 echo 'Private property in method: ' . $this->changeableVar.PHP_EOL; 30 } 31 32} 33 34// Memoria inainte sa fie alocat obiectul 35echo "Memory: " . memory_get_usage() . PHP_EOL; // Memory: 229896 36 37// Creare obiect 38$testObj = new testClass(); 39 40// Creare closure 41$closure = $testObj->closure(); 42 43// Executie closure 44$closure(); // Private property: 1 45 46// Afisare valoare curenta a proprietatii private 47$testObj->showChangeableVar(); // Private property in method: 2 48 49// Memoria inainte sa fie desalocat obiectul 50echo "Memory: ". memory_get_usage() . PHP_EOL; // Memory: 266240 51 52// Dezalocare obiect 53unset($testObj); 54 55// Memoria dupa ce a fost dezalocat obiectul, nu este o diferenta mare in memorie 56echo "Memory: ". memory_get_usage() . PHP_EOL; // Memory: 266152 57 58// Executie closure dupa ce obiectul in care a fost creata a fost dezalocat 59echo $closure(); // Private property: 2 60 61// Dezalocat closure si o data cu el mediul in care a fost generat 62unset($closure); 63 64// Memoria dupa ce a fost stearsa ultima referinta catre obiect 65echo "Memory: " . memory_get_usage() . PHP_EOL; // Memory: 230416
Callable type hinting
Inca un nou lucru introdus legat de closures introdus in PHP 5.4 este un nou “type hint”: “callable”. De fapt “callable” se refera la orice functie anonima, chiar si la un nou mod de a apela o metoda a unui obiect:
1<?php 2// O functie care foloseste type hinting 3function typeHinting(callable $a) { 4 echo $a() . PHP_EOL; 5} 6 7// Un closure 8$closure = function () { 9 return __FUNCTION__; 10}; 11 12// Apelare functie cu type hinting cu un closure ca argument 13typeHinting($closure); // {closure} 14 15class testClass { 16 public function testMethod() { 17 return __METHOD__; 18 } 19} 20 21// Un obiect de test 22$testObj = new testClass(); 23 24// Noua forma de apelare a unei metode dintr-un obiect 25$objCallable = array($testObj, 'testMethod'); 26 27// Apelare functie type hinting cu noua forma de apelare ca argument 28typeHinting($objCallable); // testClass::testMethod
Cred ca de abea acum este momentul sa spunem ca PHP suporta closures cu adevarat!
-
A devenit o traditie pentru mine sa incep retrospectiva anuala cu acest subiect.
PHP 6 este la fel de aproape de lansare cum era si anul precedent, sau acum doi ani, adica lipsit de perspectiva. In 2011, PHP 5.4 a ajuns la RC4 si probabil se va lansa in curand versiunea finala, lucru care inseamna ca inca nu se previzioneaza o data pentru lansarea PHP 6. Dar despre PHP 5.4 cu alta ocazie, este pe lista mea de “TODO” sa vad ce a ajuns in RC4.
Cum in PHP 5.3 cuvintele cheie pentru mine au fost namespaces, Anonymous functions, closures si garbage collector, in PHP 5.4 se pare ca aceste cuvinte cheie vor fi traits, din nou closures si scalar type hinting, alaturi de multe alte noutati.
Cand am scris primul meu blog anual despre PHP 6, lucram in principal la site-uri in romana, de acolo si dorinta mea pentru o versiune care sa suporte in mod nativ aceasta limba sau oricare alta fara nici o modificare. Pe atunci lucram in cea mai mare parte direct cu limbajul, de cele mai multe ori fara sa folosesc un framework . Dar de atunci a trecut mult timp si mutle lucruri s-au schimbat, acum folosesc aproape exclusiv framework-uri si platforme care m-au indepartat de limbaj oferindu-mi o noua perspectiva arhitecturala.
Dupa mai bine de un an in cadrul NCH, am decis ca este timpul pentru o schimbare. Si de data asta este vorba tot de o corporatie venita din state cu o sucursala in Romania. De data asta este vorba de Optaros. Desi nu intentionam sa-mi schimb locul de munca, am dat curs unei invitatii la interviu si pe scurt, am plecat. De mult simteam nevoia sa lucrez din nou pentru clienti externi, dupa experienta NCH unde toate proiectele erau interne, simteam nevoia de o schimbare.
Din nou proiectele sunt si mai mari, cu alte probleme de scalabilitate. Dar cred ca asta face web development-ul atat de interesant, cu cat ai probleme mai mari de scalabilitate, cu atat inseamna ca lucrezi la un proiect mai mare.
Anul trecut cuvintele cheie au fost Linux si Symfony framework. Pentru anul care tocmai s-a incheiat cuvintele cheie probabil au fost: Magento si Drupal.
Dupa o scurta perioada de lucru cu Magento, pot spune ca mi se pare incredibil cum o platforma atat de mare are atat de putina documentatie si de multe ori atat de multa inconsistenta. Este o plaforma foarte complexa cu care poti face foarte multe lucruri, dar cand vine vorba de documentatie, se pare ca abordarea se rezuma la a analiza core-ul. Venind din lumea Symfony, unde exista literalmente carti intregi de documentatie, puse la dispozitie in mod gratuit, mi se pare incredibil cat de putina si descentralizata documentatie este pentru Magento. Dar de asemenea este un subiect pentru un alt blog. Cred ca aici echipa Optaros m-a ajutat destul de mult ca sa inteleg cum sa abordez problemele.
Un alt eveniment important pentru mine acest anul trecut a fost Yahoo! Open Hack Day, eveniment tinut si in Romania in 2011. Nu stiu daca am mai vazut atata entuziasm si energie intr-un singur loc, intr-o singura zi. Pentru mine ca programator a fost o experienta de neuitat, unul din momentele care m-au facut sa-mi aduc aminte de ce am ales aceasta profesie.
In acest an am dat si examenul de certificare pentru PHP 5.3, chiar la inceptului anului. Examenul nu a fost atat de greu cum ma asteptam, desi se pare ca emotiile raman neschimbate. Faptul ca am mai sustinut un examen m-a ajutat mult, incredibil cat de multe lucruri iti aduci aminte cand le recitesti. Anul trecut mi-am propus sa sustin cel putin un examen de certificare pe an, deci trebuie sa incep pregatirile pentru urmatorul examen.
Concluzionand, 2011 a fost un an bun, plin de realizari si provocari, chiar daca nu am bifat foarte multe lucruri pe rezolutia de an, am realizat si multe lucruri care nu erau pe ea. Dar acum este timpul pentru o noua rezolutie de an.
Iar acum va urez un 2012 mai bun si mai plin de realizari! La multi ani!