Vlákno názorů k článku
Nette Framework: adresářová struktura aplikace

Autoload je sexy, zvlášť jak je implementován v nette. Ve výsledku mi ale přijde kontraproduktivní, protože zdrojový kód ztrácí rychle na přehlednosti.

Těch několik require_once na začátku každého souboru jasně popisuje závislosti - hned vidím co se používá a odkud se to bere. Pokud musím prohledat všechny soubory, abych zjistil odkud se symbol (ať je to globální proměná, funkce nebo třída) bere, je něco špatně.

Snad každý jazyk používý nějaký konstrukt pro import, include nebo podobně. A zřejmě to nebude proto, že by jeho vývojáři neuměli napsat nějaký autoload.

Mimochodem, proč všichni pro include používají nejrůznější konstrukce jako dirname(__FILE__) nebo NEJAKA_KONSTANTA_BASE_PATH, když tu máme include_path?

Těch několik require_once na začátku každého souboru jasně popisuje závislosti – hned vidím co se používá a odkud se to bere.

To je dobrý postřeh. Ale má smysl přehlednost vykoupit značným dopadem na výkon aplikace? Osvědčil se mi jiný postup. Nette je plně připravené na PHP 5.3 a jmenné prostory. S jejich použitím dojde k tomu, že se na začátku skriptů budou objevovat řady příkazů use (méně elegantní ASCII art deco ;-) ). Něco jako když se dnes člověk podívá na zdroják v C#. Na výkon to dopad nemá, ale jako dokumentační popis závislostí to funguje stejně dobře, ne-li lépe. No a já jsem si zvykl tyto příkazy, byť zakomentované, používat už v PHP 5.2.

Snad každý jazyk používý nějaký konstrukt pro import.

Ano, use je velmi podobné jako import.

Mimochodem, proč všichni pro include používají nejrůznější konstrukce jako dirname(__FILE__) nebo NEJAKA_KONSTAN­TA_BASE_PATH, když tu máme include_path?

Na include_path teoreticky není 100% spoleh, je to pomalé a vyžaduje to od vývojáře, který chce použít knihovnu, aby správně include_path nastavil. Dovedu si představit, že třeba u takového Texy by půlka vláken na fóru byla: „nejede mi to“ s odpovědí „nastavil jsi správně include_path“?

Dodal bych, že v Javě není import povinný - při odkázáni se na třídu je možné uvést namespace a při práci s návratovou hodnotou ani to. V php to asi bude podobně.
V Javě je při použití více tříd se stejným názvem někdy potřeba použít namespace.Třída, v php se tomu snad půjde vyhnout přejmenováním. Ale těžko se vyhnu přímo práci s návratovou hodnotou. Ale to zas tak nevadí.
Jinak java v podstatě má autoloading.
Lehké ot: jak php 5.3 vyřeší odkazy na ReflectionClass? Bude možné něco jako Třída.class, nebo bude potřeba použít řetězec s celou cestou a případnými problémy při refaktoringu?

To je dobrý postřeh. Ale má smysl přehlednost vykoupit značným dopadem na výkon aplikace?

Co jsem sledoval nějaké diskuse ohledně vývoje zend frameworku, tak ten dopad na výkon je skutečně znatelný. Ale:

• Nette má kompaktní verzi, kterou použiju, pokud mi jde o výkon, kde žádné include nebo autoload neřeším.
• Když použiju knihovnu třetí strany, ta si řeší includy po svém a na autoload stejně nedojde
• Pokud si napíšu vlastní knihovnu, nechci aby byla závislá na nette a jejím autoloadu
• Vlastní skripty pro jednotlivé stránky jsou zpravidla jednoduché a jedou vždy po stejné koleji, takže zbytečné includy moc nehrozí. Pokud používám nějakou složitou knihovnu, kterou využiju jen občas, můžu v jejím připadě includovat až když ji opravdu potřebuji.

Osvědčil se mi jiný postup. Nette je plně připravené na PHP 5.3 a jmenné prostory. S jejich použitím dojde k tomu, že se na začátku skriptů budou objevovat řady příkazů use (méně elegantní ASCII art deco ;-) ). Něco jako když se dnes člověk podívá na zdroják v C#. Na výkon to dopad nemá, ale jako dokumentační popis závislostí to funguje stejně dobře, ne-li lépe. No a já jsem si zvykl tyto příkazy, byť zakomentované, používat už v PHP 5.2.

Ale kolik vývojářů používajících nette dodržuje stejné konvence?

Ať si každá knihovna nebo framework uvnitř používá co chce. Nelíbí se mi ale vydávat autoload na všechno za standardní řešení (jak se může po přečtění zdát začínajícímu programátorovi). Autoload má v mnoha případech smysl, ale každý vývojář by měl vědět proč a kde ho použít.

Na include_path teoreticky není 100% spoleh, je to pomalé a vyžaduje to od vývojáře, který chce použít knihovnu, aby správně include_path nastavil. Dovedu si představit, že třeba u takového Texy by půlka vláken na fóru byla: „nejede mi to“ s odpovědí „nastavil jsi správně include_path“?

Tohle jde například řešit pomocí souboru TexyForDummies.php, který nastaví příslušnou include_path a naincluduje Texy.php

Pokročilý vývojář si nastaví include_path jak potřebuje a použije standardní řešení.

U texy je to asi jedno, beztak můžu použít kompaktní verzi, ale používat deset knihoven, kde si každá řeší includovaní souborů nějakým obskurním způsobem je peklo. Autor každé z těch knihoven se bude hádat, že jeho řešení je nejlepší a těžko říct kde je pravda.

Když už jsem si jednou jsem si vybral php, tak preferuji řešení, které mi nabízí.

Možná trošku odbočujeme od tématu. RobotLoader je především nástroj pro načítání jednotlivých knihoven vlastní aplikace. Ta už je na Nette Frameworku postavena, tudíž závislost na RobotLoaderu je v pořádku. Načítání jiných knihoven je jen možný/volitel­ný/vedlejší/pří­jemný efekt.

Nelíbí se mi ale vydávat autoload na všechno za standardní řešení.

Mně také ne.

Tohle jde například řešit pomocí souboru TexyForDummies.php, který nastaví příslušnou include_path a naincluduje Texy.php. Pokročilý vývojář si nastaví include_path jak potřebuje a použije standardní řešení.

Ale přece include_path není „standardní řešení“, nebo alespoň není „standardnější“ než „standardní“ autoloading. Prostě je to jedna z cest. A pokud mohu aplikaci napsat tak, aby její funkčnost nebyla podmíněna správným nastavením určité direktivy, tak ji tak napíšu. Nerozumím snaze mě přesvědčit, abych tam uměle tuto závislost vložil ;)

místo "pro načítání jednotlivých knihoven vlastní aplikace" má být "jednotlivých tříd"

Nelíbí se mi ale vydávat autoload na všechno za standardní řešení.

Mně také ne.

Ani tě z ničeho takového nepodezřívám. Proto jsem psal "jak se může po přečtění zdát začínajícímu programátorovi". Viz třeba "Sbohem všem require dej" Samozřejmě je to nadsázka, ale článek mi tak vyznívá.

Ale přece include_path není „standardní řešení“, nebo alespoň není „standardnější“ než „standardní“ autoloading. Prostě je to jedna z cest. A pokud mohu aplikaci napsat tak, aby její funkčnost nebyla podmíněna správným nastavením určité direktivy, tak ji tak napíšu. Nerozumím snaze mě přesvědčit, abych tam uměle tuto závislost vložil ;)

Můje první větička o include_path byla trochu mimo téma. Nebyla to vítka proti Nette ani Texy. Jenom takový postesk, proč všichni používájí require_once SOME_CONSTANT . "foo/bar.php" místo aby jednoduše přidali SOME_CONSTANT do include_path.

Souhlasím, že třeba závislost Texy na include_path je zbytečná.

Na druhou stranu includy v nette se mi už moc nelíbí. Asi je to otázka osobní preference, ale uvedu příklad (RobotLoader.php, přišel mi první pod ruku):

require_once 'Nette/Framework.php'; by mi přislo mnohem hezčí a hlavně přehlednější než require_once dirname(__FILE__) . '/../Framework.php';

Když se podívám dál, používají se v tom souboru třídy LimitedScope nebo Environment. Kde je mám hledat? Je zaručeno, že už byly includovány? Je tam schovaná závislost, kterou neobjevím, dokud neprojdu celý zdroják. Přitom zrovna závislost na Environment je hodně důležitá.

On v tom systém je, dokonce velmi přísný. Ale ten nemusí nikdo kromě komitujících znát. Z hlediska čtenáře kódu totiž stačí vědět, že třída LimitedScope (přesněji Nette\Loaders\LimitedScope) je v souboru Nette\Loaders\LimitedScope.php. Tady se pravda naráží na smutnou skutečnost, že Nette je připravené na jmenné prostory a ve zpětněkompatibilním režimu není zřejmé, že LimitedScope je ve jmeném prostoru Nette\Loaders. Je to nepříjemný dočasný stav, netušil jsem, že se verze 5.3 o více než rok opozdí.

Direktiva include_path má tu nevýhodu, že je nejednoznačná. Když napíšu include "compatibility.php", tak záleží na tom, v kterém adresáři z include_path se soubor najde jako první. Knihovna by si neměla dovolit direktivu sama přenastavit, protože když se přidá na začátek, tak mi přeplácne adresáře, ze kterých bych chtěl stejnojmenné soubory vkládat já, a když na konec, tak zase nemá jistotu, že se na ni dostane. Tím pádem je knihovna závislá na nastavení zvenku, což je otrava (a pořád zůstává problém se stejně pojmenovanými soubory v různých knihovnách).

Nezávislost na include_path je výhoda, nikoliv slabina.

Předpokládám, že svoji knihovnu mám v nějaké adresáři, takže píšu třeba include "moje_knihovna/compatibility.php" a konflikt by neměl nastat.

Aby si knihovna přidávala něco do include_path byl můj úlet, tak opravdu ne.

Dokud knihovna nemá žádné závislosti, tak trik s dirname funguje skvěle. A asi není důvod se ho pro includy v rámci knihovny vzdávat. Krom toho, že je to malinko méně přehledné, ale to je subjektivní. I když klukům v zendu to přijde asi stejně.

Neřeší mi to ale externí závislosti. Mám pro kažkou knihovnu kterou používám definovat nějakou konstantu?

Stejně jako každý jazyk má nějaký import nebo include, tak snad každý má nějakou importpath, classpath nebo podobně. Proč se jí zrovna v php bránit?

Takže při adresářové struktuře libs/Nette by v include_path byl adresář libs? To mi ale zabraňuje si adresář pojmenovat jinak, třeba Nette-0.8. Opravdu nevidím žádný způsob, jak se vevnitř knihovny bez výpočtu cesty obejít.

V aplikaci, která knihovny využívá, mám svobodu - můžu používat relativní cesty, konstanty nebo klidně i include_path, ale vnitřek knihovny by se na to neměl spoléhat.

V knihovně zpravidla nejsou jenom zdrojáky, ale často také testy, nějaké demo, readme, lincense, atd... Samozřejmě většinu nepotřebuji, ale přinejmenším při vývoji chci ke knihovně i ty věci okolo.

Takže v adresáři lib (kterých může být několik) mám např. Nette-0.8 a v něm mimojiné podadresář Nette nebo případně source/Nette (jak to stáhnu). V include path pak Nette-0.8 respektive Nette-0.8/source. Ono neuškodí mít na jednom místě sepsané všechny použité knihovny.

Vedle aplikace chci mít pouze samotnou knihovnu, tedy jenom adresář Nette. Ostatní věci okolo (testy, příklady, licenci, ikonky) mohu používat při vývoji, ale pro nasazení aplikace to není potřeba a nemělo by to tam tedy ani být.