spun primele impresii, legate de nivelul low level al codului, nu de
arhitectura framework-ului.
Mi se pare mai slaba decat se facea zarva pe aici, dar e normal. Ai riscat
destul de mult crescand asteptarile asa de timpuriu, iar unele chestii mi se
par demne de http://thedailywtf.com/.
1. Multe metode au ca ultima instructiune:
Cod: Selectaţi tot
return $this->returnToChain ();
care banuiam ce face dar am zis totusi sa verific definitia:
Cod: Selectaţi tot
# Method to do chain appending. It's easier, and sometimes
# We can add some conditions to the chain;
protected function & returnToChain () {
# Easier, than writing return (this) everytime;
return $this;
}
Daca la treaba cu "We can add some conditions to the chain" mi se pare
ok, si chiar la asta ma asteptam, comentariul "Easier, than writing return
(this) everytime" e chiar dificil de inteles.
2. Alta chestie:
Cod: Selectaţi tot
public function & __construct ($passedArgument) {
return $this->setBoolean ($passedArgument);
}
Un constructur nu poate returna decat o instanta a acelei clase. Nu stiu
ce ai vrut tu sa faci acolo, cum nu inteleg nici de ce ai return by reference.
De fapt din cate am vazut ai return by reference de cate ori returnezi un
obiect, iar cum codul ala e clar scris pentru PHP5 si nu PHP4, nu trebuie
sa iti mai bati tu capul cu referintele spre obiecte. Se ocupa Zend Engine
2 de lucrul asta. (Later Edit: se pare ca nu se intampla mereu asa. Later
later edit: se pare ca nu se intampla mereu asa in codul tau, nu in ZE2).
3. Mi se pare foarte nefolositor comentariul asta:
Cod: Selectaţi tot
/**
* With this class we chose not to provide any documentation whatsoever, because the code itself is sufficient enough to
* let the developer understand what is happening 'under-the-hood'. That's why we've set the 'access' comment parameter to it
* for private, so it will be skipped when generating documentation.
* @access private
*/
Chiar daca nu vroiai sa apara in documentatia pentru user-programmers,
ai fi putut sa lasi posibilitatea pentru developer-programmers prin tag-uri
phpdoc @internal. Iar claritatea codului rar jutifica lipsa comentariilor.
4. Folosesti prea multe switch-uri. Mai bine zis ai metode care returneaza
in functie de parametru, iar parametrul este trecut printr-un switch. Cum
documentezi set-ul de parametri acceptati?
Spre exemplu FilePath::getPathInfo(), primeste o groaza de parametri
pe care eu nu am chef sa stau sa ii caut prin cod. Mi s-ar fi parut mult
mai frumos din punct de vedere al API-ului sa ai metode separate pentru
fiecare dintre parametrii aia, sau... sa folosesti SplFileInfo sau o clasa
extinsa din SplFileInfo pentru ca ziceai ca framework-ul "se bazeaza
MASIV pe SPL".
5. Limiteaza lungimea liniei de cod la 80 de caractere altfel e greu de citit.
6. De ce e nevoie sa parsezi fisierele cu extensia .css sau .js?
7.
BE STRICT ABOUT DATA TYPES. It's the revolutionary ideea of replacing PHP types with strong type hinted variables,
* ideea that has two advantages: performance in big applications, detection of bugs in the development stage of the
* application.
Nu e revolutionar sa faci Java din PHP. A inceput odata cu PHP5 si unele
lucruri inutile pe care le-a introdus. De altfel nu cred (desi un benchmark
ma poate contrazice) ca strong type hinting poate face aplicatia mai per-
formanta. Java e ok, pentru ca e compilat, PHP nu e (oarecum). Cred ca
asta chiar ramane de vazut.
8. Nu cred ca ajuta sa ai denumiri din astea telegrafice in loc de un
nume mai comprehensibil: EML in loc de Email. Sau spre exemplu:
manageTTL, pe care eu initial l-am citit ca "manage Time To Live".
9. TheFactoryMethodOfSingleton e de fapt Registry Pattern.
10. Legat de STH. In loc sa fi obligat programatorul sa paseze un anumit
tip de parametru unei functii/metode mai bine puneai in declaratia metodei
o bucata de cod care sa faca conversia. Ai spus ca vroiai sa scapi de acele
verificari de parametri in functie. Desi ai rezolvat asta, ai dat mai mult de
tastat programatorului.
Cod: Selectaţi tot
self::renderScreenOfDeath (new S (__CLASS__);
// cred ca era mai bine asa
self::renderScreenOfDeath (__CLASS__);
protected static function renderScreenOfDeath($string) {
$string = new S($string);
}
In felul asta nu ma obligi sa instantiez o clasa S de cate ori trebuie sa
trimit un string catre metodele din framework. Recunosc insa ca ar fi
folositor sa normalizezi numele de functii care opereaza asupra string-
urilor si pe care PHP-ul le pune la dispozitie.
Ok, cam atat deocamdata. Daca mai apare ceva o sa editez postul asta
sau creez altul nou.
Apropo, incearca sa dezvolti cu error_reporting(E_ALL | E_STRICT),
caci genereaza cateva Strict standards warnings.
... si pe care doresc sa-l las sa viseze in balonul sau de aer cald ... Vreau sa intelegi ca nu te-am obligat sa te uiti pe cod, sau sa-ti placa. E un cod GPL de acum, fie iti place fie nu-ti place, e doar un cod ... ca o sa decida comunitatea ca poate fi schimbat sau nu, asta e treaba comunitatii, nu a mea. Momentan rolul meu e sa organizez acesti voluntari care doresc sa contribuie, incat sa formeze un grup care sa duca proiectul mai departe sa ia decizii mai bune decat am luat eu si sa ghideze proiectul asta, in litera de lege data de motto-ul Open Source: "Given enough eyes, all bugs are shallow." 
...
