Nette\Context – skutečně je současná implementace to pravé ořechové?

Řekl bych, že aktuální implementace není ještě hotová a ve výsledku by to mělo fungovat opravdu tak, že kontext bude přístupný v jednotlivých třídách jako $this->getContext(), tedy že bude probublávat.

Pravda, je to dlouhé a zmatené.

pekelnik napsal(a):

Navíc mi nepřijde že bychom se nějak zbavovali závislosti na statickém Environment :)

Ovšem toto je stěžejní bod. Podle mě, pokud má Nette\Context dávat smysl, třída Environment nesmí existovat.

pekelnik napsal(a):

Tak precejenom nejsem sam, akorat jsem asi svoje myslenky v jinem vlakne nenapsal dostatecne srozumitelne. A je to presne duvod, proc jsem zamrznul na poslednim commitu pred touto zmenou a cekam, co bude dal:-)

Editoval arron (2. 10. 2010 15:57)

Já jsem teda ještě nepřišel na nějaké zásadní výhody, navede mě někdo správným směrem?

Ondřej Mirtes napsal(a):

Řekl bych, že aktuální implementace není ještě hotová a ve výsledku by to mělo fungovat opravdu tak, že kontext bude přístupný v jednotlivých třídách jako $this->getContext(), tedy že bude probublávat.

Pokud je to tak jak říkáš, vývoj téhle feature měl probíhat ve vlastním branchi, ne to dát spíš nefunkční než funkční přímo do master větve.

David Grudl napsal(a):

Ani master branch není místem, kam patří jen stabilní kompletní hotové verze.

To neříkám, ale na druhou stranu by tam nemusely být věci nefunkční, ne?

Taky si myslím proto bych byl pro aby se v masteru objevilo všechno rozpracované co se „syslí“ a podílelo se na „odlaďování“ více lidí. (víc hlav víc ví) :-p (nicméně chápu i to proč to tam není)

Ha dneska mi to docvaklo: Environment je ve skutečnosti Context :)

$env = new Environment();
//...
$app = new App($env);

Rad bych upozornil ze po poslednich zmenach (pouzivani Closures) je problem se serializaci. Proc to spominam prave tady?

Protoze vzorovy skeleton obsahuje krome jineho:
$application = Environment::getApplication();

V teto chvili (netestoval jsem konkretne u skeletonu, ale ve vetsi aplikaci se mi to stalo) $application obsahuje jiz nejake Closures (pravdepodobne v contextu), co cini $GLOBALS neserializovatelnymi.

Co je problem s PHPUnit-em.

Aktualne jsem to vyresil tim ze na konci bootstrapu delam unset( $application ); aby nestrasil v $GLOBALS, na druhou stranu tim prichazim o backup/restore stavu Aplikace, t.j. ztracim zaruku ze kazdy unit test ma stejne vychozi podminky.

Narvani kontextu natvrdo do globalni promenne a nevyreseni jeho serializace by bylo primo smrtelne pro unit testing (nebo by se muselo vypnout backupovani GLOBALS, co mi prijde malo robustni reseni).

Jinak muj osobni pohled na vec je (jsem tak trochu konzervativni typ :) ):

1. jedna rozumne navrzena globalni promenna je lepsi nez lecjaky singleton a podobna havet
2. Closures jsou asi nekdy sikovna vec, ale co jsem videl aktualni commity do Nette treba ve tride Environment, tak mi puvodni kod prisel snad i prehlednejsi, nechapu jakou vyhodu ma davat do Closure funkci ktera ma 3+ radky, a proc ji nevypsat osobitne bokem.

(t.j. vice mene souhlasim s Paranoiqem, jenom upozornuji ze zrovna ted si to nerozumi s PHPUnitem)

Editoval Ped (7. 10. 2010 11:27)

V PHPUnitu to řeším úplným vypnutím serializace…

<phpunit backupGlobals="false"
         backupStaticAttributes="true">
</phpunit>

nebo --no-globals-backup

viz: http://www.phpunit.de/…uration.html#…

Ped napsal(a):

No tak ono je lepsi s tim pocitat jiz pri psani kodu a nedelat chyby, pak se nemusi psat ani testy, takze je to lepsi tuplem!

Ne, znamená to jen to, že je lepší psát testy, které nemění globální stav.

Honza Marek napsal(a):

Ped napsal(a):

No tak ono je lepsi s tim pocitat jiz pri psani kodu a nedelat chyby, pak se nemusi psat ani testy, takze je to lepsi tuplem!

Ne, znamená to jen to, že je lepší psát testy, které nemění globální stav.

V cem se tohle lisi od tvrzeni ze je lepsi psat kod ktery nema chyby?
Uznavam ze omylem napsat kod ktery meni globalni stav je podstatne slozitejsi a vyzaduje vetsi omyl nez napsani kodu s nejakou jinou beznou chybou, presto krome statistiky vyskytu dane situace rozdil nevidim.

Pri psani testu ma clovek pocitat hlavne s tim, co tam chce testovat a o zbytek by se meli postarat jeho vyvojarske nastroje, t.j. aby testovali opravdu to co napsal a aby vychozi podminky byly jednoznacne.
Backup $GLOBALS je proste jenom dalsi stupen robustnosti, jak se priblizit idealu, netvrdim ze je zrovna extremne dulezity, ale nechci se ho vzdat zbytecne.

Urcite by bylo jeste lepsi kdyby misto zalohy $GLOBALS delali rovnou kontrolu na neocekavane zmeny (t.j. ktere programator explicitne nepovolil v testu).

@David: delaji tim zalohu aktualniho stavu promennych. Nevim jestli existuje lepsi reseni, ale mne ta serializace funguje docela slusne, zatim sem ji vypnout nemusel. I ted s nette2 to zatim dokazu obejit, staci unset($application) aby to nestrasilo v GLOBALS, ale predtim slo $application serializovat. Tak mne zajima jestli ty closures jsou opravdu takovym prinosem, mne to osobne prijde jenom jako syntax sugar bez ktereho bych se obesel, ale treba to nekde pouzivas takovym stylem, ze to bez closures nijak rozumne nejde. Az tak do toho nevidim abych tohle soudil.

Ped napsal(a):

Uznavam ze omylem napsat kod ktery meni globalni stav je podstatne slozitejsi a vyzaduje vetsi omyl nez napsani kodu s nejakou jinou beznou chybou, presto krome statistiky vyskytu dane situace rozdil nevidim.

Já myslim, že to nevyžaduje omyl, ale speciální úsilí. Tzn. nastavování něčeho v Environmentu či nastavování nějakého statického atributu. A toho si všimneš…

Tak mne zajima jestli ty closures jsou opravdu takovym prinosem, mne to osobne prijde jenom jako syntax sugar bez ktereho bych se obesel

Ano, máš pravdu, všechno se dá naprogramovat i bez closures. Nicméně jejich přínos je větší než možnost mít zapnutou serializaci při testování :-P

V další verzi PHPUnitu (3.6) bude serializace defaultně vypnutá viz.: http://www.slideshare.net/…practices/35 a podpora běhu ve více vláknech je taky na programu https://github.com/…on-with-make

Můžu se ještě vrátit k otázce, proč se tedy context klonuje? Je vůbec potřeba nějaký vnější (environmentální) kontext? Nebylo by jednodušší mít pouze jeden?

Podle jakýchsi zásad DI, by se měl nejpozději před run v Application zmrazit. Což ovšem nedovoluje zpětná kompatibilita.

Netvrdím, že je to ten konkrétní důvod, ale co když si někdo přidává služby v bootstrap nebo v presenteru? to jim pak nemůžeš suše utnout přístup do contextu a v půli cesty jim ho zmrazit.

Jde o to, že třída by si sama sobě neměla být schopna měnit kontext, ve kterém je spouštěna, protože na to nemá právo (proto je zmražený), ale jen těm objektům, které sama instanciuje (v objektovém grafu jsou pod ní).

Stejně je ale Service Locator dost haprující vzor (API tříd, které ho používají, nevyjadřuje svoje závislosti – pro zjištění, čím vlastně mám Context naplnit, musím zkoumat jejich zdroják), těším se, až se do Nette dostane DI kontejner – ten se vyznačuje tím, že třída si nechává předávat všechny svoje závislosti v konstruktoru nebo metodách a většina aplikace o existenci nějakého kontejneru vůbec nemusí vědět).

Zkoumali jste už Dundeeho Diphy?

Zkoumal a subjektivně mi to přijde jako krok zpět. Sice to vypadá funkčně, ale něco mi říká, že je to až moc jednoduché.

A co backupStaticAttributes="false"? Nahrává se tvůj phpunit.xml?