Jmenné prostory – Last Call Announcement

David Grudl napsal(a):

Nakonec i v Javě se obdoby najdou (např nebo), hlavně při větším zanoření balíčku. Což je i případ nejzanořenějšího Responses.

Linky jsou stejné. Zajímal by mě i ten druhý, prosím oprav.

Špatně: Parser je to co ta třída dělá – parsuje, do pckg odebrali právě tu specializaci, ale ne to co dělá. Porovnej:

Text/Html/Parser
Parsers/Text/Html

Editoval redhead (11. 4. 2011 22:19)

Fakt nevidíš rozdíl mezi těma dvěma?

Tak jinak.

Latte/Interpret
Latte/Parser
Latte/Macros
---- vs -----
Interprets/Latte
Parsers/Latte
Macros/Latte

Jenom příklad. Druhý je analogický k současnému návrhu s Responses.

Odděluješ totiž logiku blbě. Specializaci tříd máš jako poslední úroveň a obecnost tříd jako první. Když to obrátíš dává to větší smysl (přesně to, co je na prvním linku).

Analogicky k prvnímu by byli Response třídy ve vlastních NS:

Responses\File\Response
Responses\Text\Response

Opět příklad. Tohle po tobě fakt nechci. V tom prvním linku to udělali proto, že měli třídy, které souvisí s jedním typem parseru. U Response tříd by tohle nemělo smysl, protože žádné „pomocné“ třídy nemají.

Abych to shrnul, třídy mají mít v sobě takový název, aby si věděl co dělají (Parser – parsuje, Response – odpovídá), když to obrátíš (File – soubor? snad jo, Text – nějaký dlouhý string?).

Na závěr snad už velice výstižně, kdybys chtěl zrušit duplicity:

GrepSeedJuiceManager	- bez NS
GrepSeedJuice\Manager	- správně
Managers\GrepSeedJuice	- špatně (současné Response)

Editoval redhead (11. 4. 2011 22:57)

jtousek napsal(a):

if($neco implements IResponse) nedává smysl. Ten objekt přece nic neimplementuje, to ta třída. To bys rovnou mohl místo instanceof zavést extends. Vydíš ten nesmysl?

Je to dost off-topic, ale fakt me to neda…nechci az zase tak moc protestovat proti instanceof, ackoliv ho taky nepokladam za uplne vhodne zvolene ve vztahu k interface, nicmene je objekt (trida) rozhrani opravdu implementuje.

Přečetl jsem si (konečně) pozorně rozpis změněných tříd.

MultiRouter → Nette\Application\Routers\Multiplier

A tohle mi vcelku pobavilo. Co dělá násobitel/násobič v routách? :) Co třeba RouteCollection?

Jinak se mi to až na iterátory a AppForm vcelku líbí. Nicméně jelikož třídu iterátoru z Nette jsem jaktěživ neinstancoval, tak mi to nevadí.

Prefixy jsou hnusne, je to prasarna. A vubec, zkratky jsou zlo.

Ale zase když někde uvidíš RFile, RJson řekneš si „Ha, reponse“ (což si ostatně řekneš i u FileResponse a pod, tohle je jen kraší). Vím že tudy univerzální cesta nevede, byl to jen nápad.

Editoval Milo (12. 4. 2011 10:38)

Ta idea toho škatulkování je docela zajímavá. Osobně si myslím, že je nakonec úplně jedno, jestli se použije \Nette\Responses\Text, nebo \Nette\Responses\TextResponse, protože funkcionalita jedné varianty se dá docílit i tou druhou (s menšími či většími úpravami v kódu).

Když bych dneska někde používal TextResponse, tak jsem bych ho použil tak, jak jsem ho teď napsal. Tzn., že bych si na začátku souboru udělal use \Nette\Responses\TextResponse a to by mi stačilo, protože se mi určitě nestane, že budu mít někde během práce ještě potřebu používat nějakou jinou třídu, která by se jmenovala taky TextResponse…

Když se ale ta třída jmenovala jen Text, tak bych si s tím stejně poradil. Udělal bych si use, kde bych neměl jen přímo tu třídu, ale třeba poslední část namespace (Responses). Pak bych v kódu prostě místo TextResponse psal Responses\Text. Je to samozřejmě o dva znaky delší, než kdybych psal jen TextResponse, ale funkčně je to úplně stejné. Kdyby mi to i přesto nevyhovovalo, tak můžu použít use \Nette\Responses\Text as TextResponse a jsem tam, kde jsem byl předtím.

Za mě určitě hlas pro variantu, kdy je každá část namespace co nejkratší a ať se nic zbytečně neopakuje.

Můžu se zeptat jakože je to druhé správně? Přijde mi, že to odporuje pravidlu a),

GrepSeedJuiceManager
GrepSeedJuice\JuiceManager

Neodporuje, je to podst. jméno a vím, že něco menežuje, protože hned vidíš Manager. Když ale narazím v kódu na třídu File bez NS, tak vůbec netuším, že jde o Response. A jsme zase u toho.

File u spojení FileResponse 1) není podstatné jméno, ale přídavné, 2) bez NS nepoznáš, účel třídy (File je u mě nějaká abstrakce souboru), takže odporuje celému pravidlu a).

Pořád mi není moc jasná ta potřeba některých lidí, aby jméno třídy bez namespace byla přesným popisem. Pokud třída má mít popisný název i bez namespace, tak jednoduchým řešením je prostě namespace nepoužívat a narvat ho celý do názvu třídy :-) a to se asi shodnem, že není úplně nejlepší přístup.

Objevil se tu argument čitelnosti a srozumitelnost kódu, ale když porovnám obě varianty zápisu:

<?php
use Nette\Application\Presenter,
    Nette\Application\Responses\RedirectResponse,
    Nette\Application\Responses\ForwardResponse,
    Nette\Application\Responses\JsonResponse;

class FooPresenter extends Presenter
{
    public function actionBar()
    {
        if (...) $this->terminate(new RedirectResponse(...));
        if (...) $this->terminate(new ForwardResponse(...));
        if (...) $this->terminate(new JsonResponse(...));
    }
}
?>

<?php
use Nette\Application\Presenter,
    Nette\Application\Responses;

class FooPresenter extends Presenter
{
    public function actionBar()
    {
        if (...) $this->terminate(new Responses\Redirect(...));
        if (...) $this->terminate(new Responses\Forward(...));
        if (...) $this->terminate(new Responses\Json(...));
    }
}
?>

Tak rozhodně nelze říct, že by jedna varianta byla objektivně výrazně lepší než druhá. Mně se subjektivně víc zamlouvá ta druhá; ještě bych tam použil jednotné číslo Response (podobně jako mám ve zvyku u tabulek v databázi), ale to už je celkem maličkost.

srigi napsal(a):

Mne ako koncakovy by najviac vyhovovalo \Nette\Response\TextResponse

Konečně pořádný argument!

redhead napsal(a):

V tom prvním linku to udělali proto, že měli třídy, které souvisí s jedním typem parseru.

Ty linky jsem spíš uváděl jako odpověď na to, že vidíš new File a nevíš, že to je odpověď. Totéž platí pro new Array u Javy. Ale nechtěl bych se dál posouvat cestou poukazování na nějaké drobné vady v tom či onon jazyce.

Rozdílu mezi specializací a obecností rozumím, nicméně jsou situace, kdy lze obojí spojit do jednoho slova a o to jsem se pokoušel (MappingIterator → Mapper, Filter, ButtonControl → Button, …), alternativně i konvencí (Response\File). Cílem je řešit konkrétní existující problém, který se týká i Javy (nebo alespoň její dokumentace), takže nelze to všechno šmahem smést ze stolu.

xificurk napsal(a):

• Nette\Application\Routers má zavádějící název, protože tam nejsou jen routery ale i např. Route.

Což je také router. IRouter.

Je také dobré si uvědomit, že když se půjde směrem Responses\File místo FileResponse, tak bude taky potřeba předělat i Presentery. Dneska je pořád potřeba, aby měly suffix Presenter.

HosipLan napsal(a):

Což si můžeš změnit pomocí Nette\Application\IPresenterFactory.

Což jsem si už dávno udělal, protože se mi verze bez suffixů líbí víc… Chtěl jsem jen ostatní diskutující upozornit na to, že tu řešíme případy typu TextResponse vs Responses\Text a na Presenters\My vs MyPresenter se zapomíná a přitom už ve FW je dávno vyžadováno to suffixování. Jen jsem chtěl, aby to tu zaznělo.

P. S.: Pokud bude mít někdo zájem o tu implementaci IPresenterFactory, která pracuje s těmy namespacy, můžu ji někam bokem postnout.

• Souhlasím se Šamanem a jedním namespacem Nette. (vážně!)
• Podle mě je smysl namespace vidět na příkladu FormContainer. Má metody addTextarea, addRadioList. -Špatně by bylo na začátku vypisovat use ..\..\Textarea;use ..\..\RadioList. Takže namespace by měly při používání nějakého balíku ušetřit práci psát absolutní cestu ..\..\ a stačí psát jen relativní cestu.
• Pak tu byl argument new Manager – v tu chvíli v ide vyskočí 10 managerů
• Konečně Latte\Parser vs Parsers\Latte. Tím se nezbavíme předchozího bodu, ale je zřejmé, že správné je mít Latte pohromadě a ne ho mít roztoušené v Parsers,Lexers.

Dovolím si návrh na to jak vyřešit tento problém. Jak byste všechny ty třídy zapsali, kdyby namespace neexistovaly?

@David Grudl: Líbí se mi to. Jen zamáčknu slzu za Responses\File a Cache\Storages\File. Přijde mi hezčí dostat opkaující se věci do namespace, než do názvu třídy, ale (asi se budu opakovat) nakonec je jedno, jak to bude, protože jde jen o to si zvyknout.

Hlavně, aby se ta stejná konvence dodržovala všude, aby i někdo, kdo třeba prvně začne programovat a vezme si na pomoc Nette, tak ať je rovnou veden ke standardizaci ;).

Uzavřel jsi to hezky. S tímhle jsem nanejvýš spokojen.

FYI: Dialog. okno „Máte rozepsaný příspěvek ..“ se mi zobrazí i při pokusu o odeslání příspěvku tlačítkem Poslat :)

Editoval redhead (12. 4. 2011 20:26)

dump přece existuje. Jsem rozhodně spíš pro vytvoření globální fce než aliasu, ten to zas o tolik nezkrátí.

S Davidovým rozhodnutím jsem rovněž spokojen. :-)

Jan Tvrdík napsal(a):

Teď už chybí jen přejmenovat AppForm na Form a Debug na Debugger (lépe vyjadřuje podstatu).

Přesně tak. Doufám, že se tyto dvě změny do finální verze dostanou.

Editoval jtousek (12. 4. 2011 20:34)

V jakém browseru?

Chrome(Plus)

jj taky používám podobný zkratky. Např. fci ml(), která mi pošle e-mail s hlášením. Hodí se mi v situaci kdy vím, že by něco nastat i když by teoreticky mohlo a není to taková chyba na vyhození výjimky. Potom si na mejlu zkontroluju co se stalo a jestli je vše ok a časem to odstraním.

DevNullStorage jako vážně? :D Vtipné.

Jen maličkost: Nette\Application\Routers\Namespace není přípustné, ne? U MultiRouteru.

Jan Tvrdík napsal(a):

Jak hodláte dumpovat vy?

už hodně dlouho používám globální barDump (dump je přímo v Nette)

Koukám po pár dnech jak se to tu posunulo a s výsledkem nelze než souhlasit. Teď už jen aby se to objevilo v repu

Už to v repu je ale ne v nightly-build balíku v sekci download :-)

Nevim jestli nejdu s křížkem po funuse, ale celkem se mi líbilo Controls místo UI

<?php
Nette\Application\Control\Form
Nette\Application\Control\Button
?>

U commitu je odkaz na https://doc.nette.org/updating-2-0, coz ale neexistuje. Je uz dokumentace k prechodu sepsana na jine url, nebo se na tom teprve pracuje?

Programatori si ted mohou dat pohov a ke slovu se dostavaji dokumentatori – upravit veskerou existujici dokumentaci na nove namespaces :) To bude jeste sranda.

Začal jsem převod a tak sem budu psát na co narazím…

• proč není Nette\Application\IRouter v Nette\Application\Routers ?
• proč není Nette\Forms\IControl v Nette\Forms\Controls ?
• nebylo by lepší kdyby User a IUser byly v Nette\Security ?

EDIT: pro rejpaly proč jsem to neřešil před pushnutím: protože mám raději praktickou zkušenost než jen teorii.

1 + 2 ok beru ale 3 protoze: „User authentication and authorization.“ případně udělat ze Security ACL.