[2009–11–14] Anotace: eAccelerator by již neměl být překážkou

Já bych byl zase za přístup, kdy anotace jsou jen alternativa k nějakému čistému PHP řešení (jako je getPersistentParams()). Protože komentáře, ať už obsahují cokoli, považuji za něco, co by v žádném případě nemělo ovlivňovat chod aplikace, tzn. po jejich odstranění by se aplikace měla chovat naprosto stejně.

Určitě. V javě se to normálně používá, u nějakého frameworku dokonce pro validace formulářů, což nette má vymakané lépe.

Tipuji, že měl na mysli barvu celého bloku s phpdoc, tzn. /** ... */, ne jen samotné phpdoc tagy.

Panda napsal(a):

Tipuji, že měl na mysli barvu celého bloku s phpdoc, tzn. /** ... */, ne jen samotné phpdoc tagy.

Přesně tak.

No, Annotations::add mi přijde spíše imperativní než deklarativní…
Asi by se mělo někde důrazně uvést, že Annotations::add(…) může být voláno jen těsně po definici třídy, tedy, přesně řečeno, mělo by se zabránit použití třídy před uvedením anotací.
Ale víc by se mi líbilo to getAnnotations(), tady se už asi málokdo bude snažit vecpat další anotaci za běhu. Už by to nešlo tak přirozeně.
Striktní anotace? Naprosto souhlasím. Myslím, že inspirace Javou zde může být otevřeně patrná. Jen je menší problém, že se musí oddělit dokumentační komentáře.
Btw ty compile-time anotace (např. @Getter, @Setter a @Data) by šly v omezené míře dělat přes nějaký autoloader s použitím cache. (Hlavní koncepční rozdíl od Nette šablon je v použití autoloaderu.)

Dřív jsem si myslel, že jsou anotace v komentářích špatné, ale když se nad tím člověk zamyslí, tak to zase takové zlo není. Komentáře jsou od toho, aby dokumentovaly určitou funkcionalitu, když si ale představím anotaci, která mi určuje, že anotovaná metoda bude vždy spuštěna v nové transakci, tak to je určitě věc, kterou je dobré dokumentovat taky. PHP zatím (nevím, jestli někdy bude) neumí Java-like anotace, takže ty komentářové jsou jediná možnost a jestli už David dokáže obejít limitace dané různými cachujícími akcelerátory, beru to jako správnou možnost.

Asi jediný problém vidím v tom, že teď se situace má tak, že můžu anotaci napsat prakticky jak chci a nic mě nekontroluje, jestli jsem neudělal překlep v názvu anotace, nebo parametrech. Anotace by měl něakým způsobem tedy zpracovávat už NetteLoader, když si na soubory šahá při prvním načtení. Měl by si vzít všechny anotace, co najde (teď nevím, bereme PHPDoc @author jako anotaci, nebo ne? ;)), a nějakým způsobem je prověřit – napadá mě třeba systém, kde každá anotace musí být definována jako třída a když NetteLoader na takovou anotaci narazí, předal by té třídě do nějaké statické metody jako parametr jméno třídy (metody) kde nalezl tu anotaci a parametry, co u ní jsou napsané. Ta třída by potom prověřila, jestli ty parametry jsou správně a mohla by se nějakým způsobem zachovat.

Např. třída/anotace RequiredSecurityLevel by si poznamenala všechny metody (třídy) u kterých je jako anotace uvedena (parametr by mohla být třeba minimální role uživatele), a kdykoliv by někdo přistoupil k takové anotované třídě/metodě, vyzkoušela by, jestli má k tomu oprávnění, nebo ne.

Dává to smysl, nebo to jsou jen bláboly? ;)

Ne úplně, ty píšeš něco, co by musel někdo řešit na úrovni běžného kódu. Jestli jsem to pochopil dobře, tak si představuješ, že na začátku souboru, kde bude třída, budu volat něco, co anotace řeší.

Já navrhuji tuhle starost nechat na NetteLoaderu a vytvářet pro anotace speciální třídy, jejichž nějakou statickou metodu, třeba addClass, addMethod a addAttribute by volal NetteLoader, když by objevil anotaci. Pak by se krásně řešilo, jestli je anotace dobře, nebo ne, protože by ta třída okamžitě mohla vyhodit výjimku. Pokud bude v anotaci překlep, zjistí to NetteLoader, protože nenajde tu třídu, které by předal informace.

Přesně nad tím jsem uvažoval, že pokud požádám o anotaci @security, vytvoří se objekt SecurityAnnotation (neexistující třída je fatální chyba) a v konstruktoru se mu předají parametry načtené z anotace – třída už si je bude umět sama zkontrolovat a v případě špatných datových typů nebo chybějících povinných položek vyhodí výjimku. Stále však zůstává možnost, že se seknu a místo @security napíšu třeba @secure a ono to bude vypadat tak, že uvedený člen jen anotaci nemá.

Opačný postup, kdy pro každé @xyz musí existovat třída XyzAnnotation, by byl asi docela opruzoidní, ačkoliv… Možná by se dal udělat seznam výjimek (Nette obsahuje 17 případů).

Taky jsem pro druhý postup.

Ale co o řešení /* místo /**? To taky může být problém.

Extended třídy? Tak měl bych třeba ParamAnnotation a ExcellentParamAnotation (blbější název jsem si už nemohl vymyslet), případně bych mohl mít i abstraktní třídy.

Spíš nevím jak to bude s namespace.

Honza Marek napsal(a):

David Grudl napsal(a):

Opačný postup, kdy pro každé @xyz musí existovat třída XyzAnnotation, by byl asi docela opruzoidní, ačkoliv… Možná by se dal udělat seznam výjimek (Nette obsahuje 17 případů).

Seznam výjimek by musel být přístupný přes nějakou veřejnou proměnnou. Pokud někdo bude chtít použít nějakou dokumentační anotaci, která není známa vývojářům Nette, tak by měl mít šanci ji tam napsat.

To by se teoreticky dalo řešit už v config.ini.

Kontrolovat /* */ místo /** */ by se dalo externím skriptem. Nakonec něco takového chci už delší dobu stejně přidat do frameworku, zkontroloval by BOM, přítomnost závěrečného ?> a mohl by kontrolovat i zápis komentářů.

Smysl extended tříd nevidím, viz Petr

Třídy XyzAnnotation by byly pouhé nosiče informace, místo současné stdClass. Hlídaly by jen typy a povinné hodnoty parametrů.

To já jsem právě myslel, že by i samy řešily, co se má stát. Třeba ta SecureAnnotation by se měla nahookovat na volání metody, u které je anotace @secure, a testovat, jestli ji uživatel s daným oprávněním může spustit.

Určitě ale bude i jen validace parametrů a správnosti názvu anotace krok správným směrem.

Je tam cache, která by se měla aplikovat i v případě, že Reflection k dispozici je, takže první požadavek bude o kousek pomalejší a pak už by to mělo být stejně rychlé.