Jmenné prostory – Last Call Announcement

David Grudl napsal(a):

Jsem pro Nette\Application\Responses\ForwardingResponse. Sám to používám, když mám skupinu tříd, které dělají podobnou činnost (responses, Iterators, …).

Jsem pro Nette\Application\Responses\Forward :-)

Není to proti pravidlu a) ?
Přijde mi to stejné jako:

chybně: Nette\Application\Responses\Download – nelze dovodit, že Download je odpověď

Edit: Byl jsi rychlejší :-)

Editoval Semik (7. 4. 2011 8:40)

Začínam mať pocit, že si z nás robíš prdel :) go on!

FunctionReflection → Nette\Reflection\Function – toto asi nepôjde, škoda, toto nám kazí viaceré jednoslovné pomenovania…

namespace Nette\Reflection;

class Function extends \ReflectionFunction // PHP Parse error: ...
{
}

Myslím, že Nette\Application\Responses\File a jemu podobné štruktúrovanie je síce nejednoznačné ale verím, že používa namespaces veľmi dobre. Mám k odpovediam ľahký prístup pomocou use Nette\Application\Responses;, a následne píšem Responses\File. Napíšem sa oveľa menej ako v predošlej verzii.

Odbočím: nepripadá vám to množné číslo umelé? Nechceme predsa kategorizovať, ale dať triedam čo možno najkratší názov, pričom budú oddelené funkčné celky. use Nette\Application\Response; return new Response\File.

Na druhej strane, pokiaľ to nebude celoplošné, bude to WTF (prečo táto trieda z Nette\Responses\ nemá suffix Response ale GenericRecursiveIterator z Nette\Iterators\ áno? podľa čoho viem, že tam suffix je alebo nie je? A prečo je to rôzne aj v samotnom Nette\Iterators\? v budúcnosti bežný používateľ Nette nebude poznať pravidlo a))

tipy:
AutoLoader → Nette\Loader\Nette :)
RenderResponse → Nette\Application\Response\Text
RoutingDebugger → Nette\Application\Routing\Debugger
Debug → Nette\Debugger
DebugPanel → Nette\Debugger\DefaultPanel
IDebugPanel → Nette\Debugger\IPanel
DebugHelpers → Nette\Debugger\Helpers

na záver:
IComponent → Nette\IComponent
Component → Nette\Component
IComponentContainer → Nette\Component\IContainer
ComponentContainer → Nette\Component\Container

A… som jediný, ktorému pripadá namespace DI úplne mimo?

Doplnené:

namespace Nette\DI zrušiť (pretože mne príde čiste kategorizačné)

Cache → Nette\Cache
ICacheStorage → Nette\Cache\IStorage
ICacheJournal → Nette\Cache\IStorageJournal

V duchu mojich predošlých tvrdení by mohlo byť i namespace Nette\Exception:
InvalidStateException → Nette\Exception\InvalidState
NotImplementedException → Nette\Exception\NotImplementedFeature
NotSupportedException → Nette\Exception\NotSupportedFeature
DeprecatedException → Nette\Exception\DeprecatedFeature
MemberAccessException → Nette\Exception\InvalidMember
FatalErrorException → Nette\Exception\FatalError
… čo ale robí problém pri výnimkách hlbšie v štruktúre.

… Takže predsa len zametáme, akurát do Nette\Utils :)

na prvý pohľad je zdanlivá nekonzistentnosť v Nette\DateTime a Nette\Utils\String, lenže je treba povedať, že sa jedná o triedy s dosť odlišnou funkcionalitou. Kým Nette\DateTime objektovo reprezentuje dátum a čas, Nette\Utils\String reprezentuje súbor funkcií na prácu so stringami…
viem, že sa to už raz nedoriešilo, ale naozaj by nešlo Nette\Utils\String::<func>() → Nette\String\<func>()?

Editoval kravčo (7. 4. 2011 11:48)

Nette\Application\Responses\String bez NS → String zní spíš jako/se může plést se String helper třídou a odporuje a), tak StringResponse?

Osobně bych tu délku až tak nehrotil, stejně to doplní IDE, často stačí napsat 2 znaky…

kravčo

Taky mi všude ty množný čísla nějak rozčilujou… Na DI se ti nezdá název nebo to, že to existuje? Pokud se to týká názvu, taky bych tam nedával zkratku, ale napsal to v plné verzi DependencyInjection.

Nejnovější kravčovi nápady mi přijdou vyloženě šílené :)

když čtu ty vaše navrhy, tak jsem vždycky rad, že David to většinou dělá podle sebe :D
Response\Text? tripple wtf? a co když to budou čísla =P

To je otřesné :) Nechceš si na to přemýšlení vzít ještě pár týdnů a pak založit „Last Last Call“? Při psaní názvu třídy od půl namespace skřípu zuby. Strašně mi to vadí, buď celý namespace, nebo jenom třída.

Já si vždycky myslel, že třída se má jmenovat podle toho co dělá, nebo představuje. Není to tak dávno, co jsi se urputně bránil stylu Symfony. Když už teda podléháš, tak alespoň podléhej většině. https://github.com/…pping/Driver Většina to dělá takhle (a teď nemám na mysli to, že název třídy odpovídá složce, to v dobách RobotLoaderu není vyžadováno)

./Doctrine/ORM/Mapping/Driver/XmlDriver.php => Doctrine\ORM\Mapping\Driver\XmlDriver;

Byť mi přijde, že popisnější by to bylo v namespace Drivers. Voni ti kluci co napsali Symfony (nebo Doctrine, …) taky nebudou úplně vypatlaní…

Editoval HosipLan (7. 4. 2011 14:59)

Response\Text je nesmysl, ve mně to evokuje odezvu s typem text/plain. Nechal bych to tedy jako Render, protože je v ní echo.

HosipLan napsal(
teď nemám na mysli to, že název třídy odpovídá složce, to v dobách RobotLoaderu není vyžadováno)

Jak se říká, jen blbec nemůže změnit názor, avšak v tomto případě vůbec nevím, co se snažíš říct. Buď konkrétní.

Jsem pro Nette\Exceptions a přejmenování AppForm na Form…

David Grudl wrote:

Ještě aby nedošlo ke zmatení. Příklad:

• ArrayIterator → SPL\Iterator\Array ŠPATNĚ
• FilterIterator → SPL\Iterator\Filter DOBŘE

Vnímáte ten rozdíl?

Ne. (Třída se nemůže jmenovat Array, ale to předpokládám, že není ten důvod, proč je první varianta špatná.)

zapisovat namespace od půlky mě doteď nenapadlo a docela se mi to líbí (Response\File, Latte\Filter, Http\Request). názvy jsou tak popisné, jak je komu libo. zkracovači si to můžou zkrátit. ti co se v tom chtějí vyznat napíšou poslední dvě části názvu. neporušuje se pravidlo duplicity. mezi FileResponse a Response\File je rozdíl jediného znaku. samá pozitiva a jistoty…

upozornění: nejde to dohromady s množným číslem u katalogizačních ns: Driver\Mysql je určitě lepší než Drivers\Mysql

Editoval paranoiq (7. 4. 2011 20:02)

kravčo napsal(a):

FunctionReflection → Nette\Reflection\Function – toto asi nepôjde, škoda, toto nám kazí viaceré jednoslovné pomenovania…

Class a Function to kazí, co s tím?

*Odbočím: nepripadá vám to množné číslo umelé?

Hodně mi to připomíná (nerozhodný) problém jednotných a množných čísel u DB tabulek.

podľa čoho viem, že tam suffix je alebo nie je? A prečo je to rôzne aj v samotnom Nette\Iterators\? v budúcnosti bežný používateľ Nette nebude poznať pravidlo a))

Někdy prostě neexistují jednoslovné názvy jako Button, Checkbox a musí se použít přídavné jméno + podstatné jméno, jako HiddenField. Ten přitom nikomu nevadil. Takže v tom nevidím tak zásadní problém. BTW: Lze nazvat RecursiveIterator jako Recursor?

Cache → Nette\Cache
ICacheStorage → Nette\Cache\IStorage
ICacheJournal → Nette\Cache\IStorageJournal

Spíš bych držel jedno téma vždy v jednom NS. I kvůli dokumentování. Případ Nette\Cache a podobných se dá považovat za jakousi default třídu NS, takže bych spíš uvažoval jen o vytváření jejich pevných aliasů.

V duchu mojich predošlých tvrdení by mohlo byť i namespace Nette\Exception:
InvalidStateException → Nette\Exception\InvalidState

Tady (a dalo by se to říct i v případě iterátorů) bude vhodnější dodržet konvenci PHP, ačkoliv logika věci by byla pro Nette\Exception\InvalidState (s rezervou: nevím, zda lze brát NotSupported nebo Deprecated za podmět).

… Takže predsa len zametáme, akurát do Nette\Utils :)
na prvý pohľad je zdanlivá nekonzistentnosť v Nette\DateTime a Nette\Utils\String.

Ano, trošku váhám se zametáním. Nicméně zrovna Nette\Utils\String je úplně špatně pojmenovaná třída a Nette\Utils\StringUtils je nepěkné, takže se stejně vrátím k Nette\StringUtils. BTW utils (užitečnosti) je asi lepší než tools (nástroje).

• Pokud čistíme jmenný prostor Nette tak Nette\Html → Nette\Utils\Html a Nette\DateTime → Nette\Utils\DateTime.

V případě Html to zvažuju, ale DateTime mi nesedí. Pokud čtu Nette\Utils\cosi jako cosiUtil, tak dělat objekt DateTimeUtil mi přijde divné, je to přece ryzí DateTime.

HosipLan napsal(a):

Tvrdím, jako Bojovyletoun, že název třídy by měl být dostatečně popisný (!= zbytečně dlouhý), část názvu by měla být v namespace, ale funkce třídy (request) a odlišení od ostaních funkcí (http) by měla být v názvu.

Bavíme se o velmi tenké hranici, mezi odlišením v rámci NS nebo odlišením v rámci všeho. Docela mi dostačuje odlišení v rámci NS.

vojtech.dobes napsal(a):

Tyhle „rozebrané“ namespacy a krátké názvy tříd podle mě využívají to nejlepší, co mohou jmenné prostory přinést.

Taky se mi zdá. Buď lze s NS bojovat, nebo je šikovně (vy|zne)užít.

Proč je Nette\Utils\String špatně pojmenovaná třída? Nevidím rozdíl oproti např. Nette\Application\Responses\Json.

„Aplikace vrátila JSON“ zní přirozeně.

Vidím rozdíl mezi třídou představující řetězec a třídou představující nástroje pro řetězce.

Davide, jestli chceš doporučovat práci se třídami ve tvaru Iterator\Filter atp, bylo by dobré, to dodržovat globálně, viz Response\Json. Sice se mi to nelíbí (nějaký mentální blok kvůli bůhvíčemu), ale nemám proti tomu argumenty. Tak to aspoň udělej konzistentní, díky :)

HosipLan napsal(a):

Tak to aspoň udělej konzistentní, díky :)

Jestli máš na srdci něco konkrétního, tak to napiš, fakt nevím, jak si tvé připomínky vyložit.

HosipLan napsal(a):

Tak píšeš, že chceš prosazovat zápis Driver\Mysql ale v přehledu změn máš pořád Responses\Json, je to trochu matoucí :)

Kde píšu že chci prosazovat Driver\Mysql? A co by mělo být místo Responses\Json? Se trošku snaž, to mám z tebe tahat jak z chlupaté deky?

David Grudl napsal(a):

A co by mělo být místo Responses\Json?

No přece Response\Json :-D

David Grudl napsal(a):

Nejrozumnější a nejpřirozenější by bylo zavést jmenné prostory obráceně, tj. místo Nette\Application\Response\Json používat Json\Responses\Application\Nette nebo InvalidArgument\Exception\Nette či Filter\Iterator\Nette. Výhodu to má i v tom, že by se všechny třídy jmenovaly Nette, tudíž by se programátor nemohl splést.

:D

Dlho sa o tom diskutuje. Urob to tak ako si urobil pri https://forum.nette.org/…aciho-jazyka a bude kľud :))

Tak abych zase rozpustil ledy. Současný návrh je strašný.

Nette\Application\Responses\File myslíte vážně?? Až bude NB umět automatické psaní use a já budu moct napsat pouze (necelý) vlastní název třídy bez NS a pak Ctrl+Space, Enter, tak budu mít jako v kódu třídu File, která nemá se souborem vlastně nic společnýho, protože je to vlastně odpoveď serveru? To samé \Text atd.

Hodně věcí teď porušuje pravidlo a) a to nemyslím podstatným jménem, ale že nevystihují podstatu třídy bez uvedení namespace, což považuji za mnohem důležitější než že to musí být pods. jméno (například IRenderable je naprosto správný název interfacu)

Sice bych mohl napsat třídu s poslední úrovní NS, ale proboha proč?? Navíc tam budu mít ohavné lomítko. A nemluvte tady o délce, za chvíli nějaké use nebude muset psát vůbec.

Zamyslete se znovu nad tím, co tu obhajujete.

redhead: Ty to pořád srovnáváš s Javou. A ta má názvy všech tříd tak strašně dlouhý, že by se obešla i bez jmenných prostorů (packageů).

redhead napsal(a):

Tak abych zase rozpustil ledy. Současný návrh je strašný.

Nette\Application\Responses\File myslíte vážně?? Až bude NB umět automatické psaní use a já budu moct napsat pouze (necelý) vlastní název třídy bez NS a pak Ctrl+Space, Enter, tak budu mít jako v kódu třídu File…

A až bude NB umět automatické psaní use s poslední úrovní NS, bude problém vyřešen ;-)

…která nemá se souborem vlastně nic společnýho, protože je to vlastně odpoveď serveru?

No a taky je to soubor, a taky je to objekt (FileResponseObject).

Mimochodem, všiml sis problému ve slovech „je to odpověď serveru“? Pokud to je odpověď, pak by nemělo jít o implementaci rozhraní IResponse, ale o potomka třídy AbstractResponse (is-a vs -able or can-do). Jelikož proti IResponse nic nenamítáš, mohu ti rozporovat, že to vlastně odpověď serveru není ;) Je to soubor, jehož lze použít jako serverové odpovědi.

redhead napsal(a):

Jde mi ale hlavně o popisnost těch tříd. Co mi řekne třída File nebo Text bez namespace? Nic.

Předně: těmto námitkám velmi dobře rozumím, protože stejným způsobem bych namítal sám, nicméně zajímavé je i oponovat.

K praktického hlediska je dokumentace java.io (platí i pro .NET) neúhledná hromada tříd rozdělená na tři skupinky interface, class, exceptions. Mnohem praktičtější by bylo rozdělení na okruhy Reader/Writer, InputStream/OutputStream a ostatní. Mohly by se označit nějakou Javadoc anotací. A tu by mohl respektovat nejen generátor dokumentace, ale i IDE, čímž by se zjednodušilo psaní tříd. To by byl jasný praktický přínos.

Primárně však chci říct, že určitý rozlišovací nedostatek v Javě vidím. V Nette ho rozhodně mít nechci a vlastně je jen otázka, jestli k tomu využít anotace nebo namespaces.

V javě by si nikdo nedovolil udělat třídu java.io.readers.Buffered, protože radši budu číst o 6 znaků delší

To je ale velmi, velmi zavádějící přirovnání. Jak si můžeš všimnout, taky nechci použít Nette\Iterators\Recursive.

Třeba udělat nový význam pro slovo implements.

if($neco implements IResponse) vypadá fáákt dobře.

Když už ses teda začal dál pitvat do Javy. Tak mu upřímně řekni co si budeš myslet o tomto kódu, když ho při procházení souboru najdeš:

File f = new File("a.txt");

Co? Abstrakce nad souborem „a.txt“? Ahá, ale bacha radši vyscrolluj nahoru, páč třída File je v package java.io.writer!

Co se týče toho Buffered, to jsem napsal schválně, protože to dodržuje stejný scénář (ano, vím, není to podst. jméno..), ale je to stejně tak nepopisný název třídy jako Response/File bez ns.

Ano, je dobré oponovat a sám jsem nad tímto způsobem ns také dost přemýšlel, ale když jsem si pak představil práci s takovýmto kódem, tak jsem to naprosto zavrhl.

Já v tom tolik výhod zas nevidím. Navíc, někteří psali, že budou psát: Response\File v čem je to jiné než psát FileResponse (bacha! o jeden znak kratší, whee).

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?