Nová podoba jmenných prostorů: finalizace

David Grudl napsal(a):

PHP je tradičně vytýkána nesourodost v pojmenování tříd a funkcí. Tohle bych do Nette fakt zavádět nechtěl, tj. dávat různá jména podle toho, jako moc cool mi ta která funkce připadá.

To jsem myslel spíš jako podvědomý působení.

ad počet tříd: neříkej, že argument s počtem tříd na tebe neplatí a raději napiš jasný důvod, proč by neměl platit.

níže…

Já chápu namespace jako způsob, jak 1) zabránit konfliktu názvů (to je prefix Nette\)

Já bych za konflikt názvu považoval třeba i situaci Form vs. AppForm, což bych řešil jako Nette\Forms\Form a Nette\Application\Form. Když se tomu nebudeš bránit, takové věci pak začnou vyskakovat na každém rohu.

2. oddělit nezávislé funkční celky (to je Forms\ nebo Forms\Controls). Jednu třídu jako funkční celek nevnímám.

Proč by jedna třída nemohla být funkčním celkem? Pokud má na starosti jednu specifickou úlohu, je to funkční celek. Počet tříd je implementační detail (i v případě počtu === 1).

Dále: podobnou úlohu jako jmenné prostory plní i statické třídy.

Jen v případě namespacování funkcí, ale to víme.

Nedokázal bych odpovědět na otázku, proč se v Nette píše Nette\Neon\Neon::decode() a ne Nette\Neon::decode().

To fakt chceš udělat Neon parser staticky?

(Nette\Tools\Neon::decode() mi nevadí, ale nemám pocit, že verze bez nebo s Tools by byla v něčem lepší).

To je to, že v namespacu Nette (čili v kontextu frameworku globálním namespacu), by mělo být co nejméně tříd. Nějaké to Object a Framework a skoro šmytec.

Moje představa o ideální situaci je taková, že pro distribuci části frameworku (např. Latte, Debug, Latte + Templates, Neon, Image, Finder, … je toho hodně, co dává smysl i bez zbytku frameworku), by stačilo vytáhnout odpovídající namespace, třídy z namespace Nette a jasné závislosti (pro Latte Tokenizer). Čili jeden jmenný prostor pro každou feature a v tom globálním žádné zbytečnosti :)

Pokud by si napsal nějaký hyper parser, o kteŕm by se dalo říct, že je něčím opravdu výjimečný, novátorský, atd, pak asi ano. Koukal bych na to jako na jednu z předností fw a vyčlenil bych to do vlastního ns…asi ano…

Sakra 1 hodina ráno a já nestačím odpovídat, aby mezitím nepřibylo X příspěvků…Asi to nechám na zítra.

Editoval Ondřej Brejla (7. 2. 2011 0:43)

už se v tom zase začínám orientovat a chápat. a musím říct že souhlasím s Ondrou i Honzou. Hlavně myšlenka „vzít namespace“ se mě hodně líbí (vzhledem možnosti vzniku balíku pro šablony, formuláře, laděnku a další s následnou integrací do něčeho jiného než nette – třeba Drupal).

Výborně, tak to máme stejné cíle.

Že bych rozlišoval podle složitosti jak něco napsat, toho jsem si nevšim. Do téhle kategorie mi spadá spíš názor, že v namespacu nemá být jedna třída. A s tim vykopírováním – vždyť je přece jasné, že jakmile má smysl něco samostatně vykopírovat, je to samostatný funkční celek!

Nijak Davide, pokud nebudou části frameworku opravu funkční samostatné komponenty, nemá význam takový argument.
Občas se tu objeví někdo, že by chtěl použít jenom šalbony, routy, debug nebo něco jiného a stejně si musí vykopírovávat Object a ObjectMixin, pak zjistí že v šablonách je použito Html a String, jsou tam různé vyjímky, třeba pro regulární výrazy, atd atd…

Co je špatně na Nette\Syntaxes, Nette\Formats, … kam by se daly tyto encodery (Neon, Json, …)?
A co je špatně na Nette\Types? Vždyť přece neon je typ souboru, json je taky typ souboru a oba pracují s jejich obsahem/formátem, nebo ne? Latte je taky typ souboru. Myslím, že by nebylo od věci vyčlenit tyto třídy pracující s různými typy do samostatého namespace a v rámci pořádku je vyčlenit do složek podle typu, se kterým pracují a klidně je nechat v tom společném namespace.

Fakt nevím, jakou přidanou hodnotu pro mě bude mít Nette\Neon\Neon::decode, či Nette\Tools\Neon::decode. Pro ty, pro které to význam má, odkazuji na symfony. David narozdíl od odstatních nad tím přemýšlí. Tyto prvoplánové výkřiky „to je větší, tak si zaslouží vlastní namespace“ jsou fakt dost primitivní. Vždyť to je ta krása na nette, že neřeším jestli cache je dummy, memcache, nebo filecache. Stejně tak nechcu řešit, jestli Davidova implementace jsonu je primitivní, nebo složitější parsovač jako je neon.

HosipLan napsal(a):

Občas se tu objeví někdo, že by chtěl použít jenom šalbony, routy, debug nebo něco jiného a stejně si musí vykopírovávat Object a ObjectMixin, pak zjistí že v šablonách je použito Html a String, jsou tam různé vyjímky, třeba pro regulární výrazy, atd atd…

Pokud jde o ty závislosti tak by možná mělo smysl udělat něco jako má jQuery UI. Že si člověk navolí, které komponenty chce a ono si to už automaticky dohledá co dalšího je potřeba a pak nabídne ke stažení minified verzi jen toho, co člověk chce. (např. pro statický web jen laděnku a šablony + jejich závislosti jako object)

EDIT: Tyto závislosti by bylo asi nejlepší řešit pomocí nějakých anotací jako @dependency Nette\Object.

Co je špatně na Nette\Syntaxes, Nette\Formats, … kam by se daly tyto encodery (Neon, Json, …)? A co je špatně na Nette\Types?

K umístění Json, Neon a Latte. Návrh Nette\Syntaxes nebo Nette\Formats se mi myšlenkou zamlouvá, ale tyto konkrétní návrhy se mi příliš nelíbí. Trochu víc se mi líbí Nette\Syntax. Žádný vlatsní lepší nápad bohužel nemám.

EDIT:
Rozlišovat Neon a Json podle toho, jak jsou složité a jestli používají nativní PHP fce je dle mého názoru chyba.

Editoval jtousek (7. 2. 2011 12:44)

Přesně tak. Napadlo mě to taky už dříve a teď se to hodilo jako reakce. Navíc zrovna nedávno se tu řešilo, že minified verze nefunguje pokud na serveru není PDO (přestože daný web Nette\Database nepoužívá).

Omlouvám se za off-topic. Pokud je tu více lidí, kterým se tento nápad zamlouvá, můžeme otevřít nové téma.

Dakujem HospiLanovi a jtouskovi (dufam ze to sklonujem dobre) za podporu mojej myslienky s Nette\Syntaxes apod ..

Neviem stale mi pride, ze sa tu viac menej handrkujeme o tom, ze Neon je cool a preto musi mat vlastny NS. Suhlasim s Ondrom Brejlom, ze Neon ma podla mna velky potencial a prinasa nieco hodne dobre a intuitivne ale proste argumenty ktore tu padaju mi pridu nie koser a najviac sa mi pozdava to co vravi a cim argumentuje David.

Tiez nechapem co je zle na Nette\Syntax? Presne to popisuje semantiku toho co v tom bude:

Nette\Syntax\Json::decode();
Nette\Syntax\Neon::decode();
Nette\Syntax\LatteFilter::formatString();

Podla mna prehladny a najme samopopisny kod.

@westrem: Přesně tak. :) Namespace Nette\Syntax mi ze všech doteď navrhovaných možností připadá nejlepší.

@paranoiq: Ano, to už mě taky napadlo (a jsem pro aby tohle ve frameworku bylo). Přesto ale lidi často chtějí pužít jen určitou část Nette a to, že celý framework zabere jen několik KB je moc nezajímá a minified verzi odmítají protože se tam tvoří mnoho tříd, které nepotřebují. Nechci polemizovat nad tím, zda je to dobře nebo špatně, prostě to tak je a jiné řešení než download ala jQuery UI na to asi není.

Nette\Syntax → Nette\DSL (domain specific languages)?

Ale jinak by mi asi taky stačil namespace Nette, jak už tady někde padlo :-)

DSL mi přijde jako obrovské WTF…

LOL. Ale jo, mně v podstatě taky. Byl to jenom rychlý nápad a nějak přeskočil autocenzuru. Ale Syntax mi nepřijde přesné, to byl asi důvod, proč jsem hledal alternativu: chtěl jsem konstruktivní kritiku, ne jako tuhle ;-)

David Grudl napsal(a):

Minifikovana verze a PDO je mesic stary vyreseny bug minifikatoru, ne?

Potvrzuji, nyní otestováno. Ono je to těžké sledovat, v diskusi se nic neobjevilo (napravím), issue na githubu byla uzavřena bez komentáře. Takže jsem jako autor objevení bugu taky žil v domění, že „bude opraveno“.

Pardon za mírný OT.

Dr.Diesel napsal(a):

Asi budu pravdepodobne dle diskuse sam, ale nechapu, proc se opet travi cas prejmenovavanim namespacu, presouvanim souboru apod.
https://github.com/…2a608567b329
Zneplatni se dosavadni konvence, samply, code-snippety apod., i kdyz budou zmeny zpetne kompatibilni = Opet se to zacne cele stepit, tak jako doposavad 0.9 vs. 1.0 (2.0) Pri kazdem dotazu bude muset resit, kterou PRESNE verzi ma dany vyvojar v projektu. Cilem je pravdepodobne na jednu stranu poradek a „citelnost“, z myho pohledu je to vec, co mi na Nette vadi – Neustale zmeny/prekopavani/prejmenovavani stavajiciho vs. Rozsirovani+rozvoj / fixy…

Palec nahoru. A je nás víc.

Juan napsal(a):

Ginny napsal(a):

Dr.Diesel napsal(a):

…

Palec nahoru. A je nás víc.

Palec dolu. Zachovávání BC brzdí vývoj a podle mě do verze 2.0 prostě nepatří žádné konstrukce, které by měly být zachovány jen z historických důvodů. Konzervatismus tohoto typu je podle mě velmi špatná vlastnost pro vývoj moderního SW.

Palec nahoru. x)

Verze 2.0 je přelomová. Při jejím vývoji už bylo BC breaků hodně a pokud je to pro dobro věci tak ať jich je klidně dvojnásobek. Osobně si myslím, že by se z frameworku před vydáním v2.0 mělo odstranit všechno, co v něm je jen z historických důvodů (např. vše, co je označené jako deprecated – pokud něco takového ve frameworku ještě straší).

Juan: ty si zase přiletěl asi z měsíce, že? Moderní software, kde?
Protože Nette na to nevypadá. Fungující věci v něm byly zrušeny a nové nefungují.
A nebojme se být konkrétní. Snipety. Context – obsahoval víc než tři měsíce vážný bug.

Dalších x věcí je neustále předěláváno, přejmenováváno (latte, imagick, namespacy).
Dalších x věcí chybí: nějaká rozumná podpora – lokalizace routeru, vlastní template.

Něříkám, že tyto změny nejsou třeba, říkám, že v tuto chvíli je to opravdu to poslední, co brání stát se nette „moderním softwarem“.

Editoval hrach (10. 2. 2011 23:56)

Dr.Diesel napsal(a):

Na ktere verzi mam podle tebe v takovem pripade nyni zalozit Nette projekt, abych ho jenom behem vyvoje 10× neprepisoval?…

Samozřejmě na aktuální stable verzi.

Dobře tak ne. :) Já sám vyvýjím na alpha verzích. A ano, také jsem během vývoje framework asi 10× mazal, dával tam novou verzi a následně řešil nekompatibility. A ano, taky mě to vadí.

Vzhledem k tomu, že se ve frameworku chystají velká změny (např. namespaces, formuláře) jsem se poté rozhodl framework zmrazit a už jsem jej neupdatoval. Není nutné aby projekt fungoval na finální 2.0 tak proč to pořád řešit? Když tam byla nějaká kritická chyba tak jsem ji opravil ručně. A taky mě to stálo některé nové featury, ale to zas tak nevadí. Celé to považuji za riziko, které jsem na sebe dobrovolně vzal, když jsem se rozhodl použít alpha verzi. A nemám s tím problém.

Dle mého názoru se už dávno měla vydat ostrá větev 1.0, sice ne se všemi plánovanými novinkami, ale prostě aby byla novější stable než prastará 0.9. Bohužel se tak nestalo, takže se musíme spokojit s alpha verzemi. Mě osobně to zas tolik nevadí a rozhodně nechci brzdit vývoj kvůli zpětné kompatibilitě apod. Zpětná kompatibilita v alpha verzích funguje tak 10–50 commitů dozadu a IMHO je to tak správně.

Takže závěr: Nechceš problémy? Použij stable. Chceš nové funkce? Použij alpha, ale uvědom si, že alpha je alpha.

hrach napsal(a):

Verze 2.0 je přelomová.

jop, tak to je pravda, to co fungovalo včera už dneska nefunguje

I tak se to dá říct. XD Řešení: použij včerejší verzi. ;)

Editoval jtousek (11. 2. 2011 0:15)

Pánové, tohle už je flame na zamčení. Ale jak říká jtousek, vyžadovat 100% stabilitu a zpětnou kompatibilitu od vývojové verze není zrovna normální :)

jtousek napsal(a):

Dr.Diesel napsal(a):

Na ktere verzi mam podle tebe v takovem pripade nyni zalozit Nette projekt, abych ho jenom behem vyvoje 10× neprepisoval?…

Samozřejmě na aktuální stable verzi.

Dobře tak ne. :) Já sám vyvýjím na alpha verzích. A ano, také jsem během vývoje framework asi 10× mazal, dával tam novou verzi a následně řešil nekompatibility. A ano, taky mě to vadí…

Proste mi to cim dal vic pripomina akademickou pudu odtrzenou od reality. „Tohle pojmenovani uz nas tam dlouho stvalo, tak prejmenujem pres 70 souboru a jejich namespacu (bez testu, viz commit) a hned je co delat“.

Abych nepusobil nevdecne, s Nette si od 1.0a pomerne rozumim a pri vyvoji mi prakticky nic nechybi, novy „rychlejsi zapisy“ nebo „prehlednejsi pojmenovani“ me nepali a co jsem potreboval si upravil / dopsal.

Nekdy to byl wow efekt (predevsim komponentovy model),

nekdy hardcore WTF efekt (zamykani veskereho generovani cache, kdyz se v CELE APLIKACI generuje jina (ne ta sama) https://forum.nette.org/…e-v-aplikaci – vysledna odpoved je tristni)

Davide, já osobně:

• Context: předtím to fungovalo a neměl jsem problém. neměnil bych (bohužel já vydělávám tím, že to funguje, firma mi nic neda za to, že je to DI… :()
• Snippety: předtím to fungovalo (byť magicky), teď nefunguje, nevím jak opravit. neměnil bych, dokud bych nevymyslel, jak zachovat funkčnost.
• Nové formuláře: slíbil si, že je o víkendu zveřejníš, buď to máš naprogramovaný a jen jsi to z nějakého důvodu nezveřejnil, nebo to naprogromavaný nemáš. Pokud se jedná o variantu a, přijde mi zbytečné posílat patch, pokud se jedná o variantu b, řekni, zkusím navrhnout vlastní změny formulářů myšleno vážně.
• Nette\Debug\Debug vs Nette\Diagnostics\Debug neměnil bych,

atp… posilat revert patche asi nema cenu :D

Editoval hrach (11. 2. 2011 0:41)

Reknu to jinak – Kam se timhle Nette posunulo …?

Jednou z nejlepších vlastností vývojáře je perfekcionismus. Toho je v Nette vidět spoustu a proto je to tak dobrý produkt. Tyhle názory mi připomínají prvotní protesty proti n:atributům v šablonách. A jak jsou teď užitečné…

A už se na ten flame fakt vykašlete.

Tak buď můžete věcně řešit konkrétní věci (na Context něco nefunguje? vytvoř vlákno, napiš co), nebo nesmyslně naříkat (chceme nové formuláře vs. nechceme, aby se něco měnilo) či dokonce vytvářet FUD (někoho se dotklo nějaké přejmenování třídy?), volba je na vás ;-)

implementace feature requestu + reportovanych bugu

Tak posílejte patche. Je to snadné.

To jsou samé nářky a výmluvy, až to liská. Naříkáš, že ti chybí nějaká featura nebo oprava bugu, ale když řeknu „pošli patch“, tak to totálně překroutíš někam jinam. Šíříš tady FUD, jak se přejmenovávají třídy, ale žádné se nepřejmenovaly. Že „plýtvám“ svým časem na komity, které neshledáváš užitečnými? No a? Nejsem tvůj zaměstnanec. A už vůbec se nenechám buzerovat, diktovat si, co mám nebo nemám dělat, podle nějakých dojmů.

Ahojky. Taky se přídám, ať zábava nestojí ;). V následujícím textu používám slovo uživatel a mám tím na mysli člověka, co pracuje s Nette, takže vlastně vývojáře. Ale uživatel se mi zdá hezčí ;).

Vývoj Nette, jak doteď probíhal, celkem beru. Nevidím do toho tak hluboce, abych, jako někteří z diskutujících, mohl říct, že se některými změnami spíš přidělávají nové problémy, než řeší staré. O to tu ale ani tolik nejde.

Je potřeba si uvědomit, že vzhledem k tomu, že Nette není vyloženě komerční záležitost, tak se nové featury a opravy chyb neodvíjejí tolik od požadavků uživatelů, ale spíš od toho, co zrovna vývojáře Nette nejvíc v danou chvíli pálí. Tohle není myšleno nijak negativně, jen to chci zdůraznit pro ty lidi, kteří si to neuvědomují.

Pokud skutečně někdo potřebuje, aby se na nějaké nové feature, případně opravě chyby, pracovalo, tak to buď musí udělat sám, nebo to na někoho splašit a případně tomu někomu i zaplatit. Nevím, jak by se k tomu stavěl třeba David, a jestli to už třeba není nějak řešené, ale napadá mě, že by nebylo úplně od věci, kdyby se dalo pro feature requesty/opravy chyb nějak hlasovat, příp. je nějak finančně dotovat, aby bylo vidět, co komunita vážně chce/nechce…

Já vím, že na ten předchozí odstavec je jasná reakce „Open Source SW nemusí nutně reflektovat podněty jeho uživatelů“, která to celé ukončí. Ale já si myslím, že dneska už je i Nette v takovém stavu, že by se na podněty uživatelů měl brát ohled. Zkuste se nad tím všichni zamyslet ;).

Aby tenhle příspěvek nebyl úplně off topic, tak se ještě zastavím u těch namespaců. Jako uživateli mi je úplně jedno, jak to v danou chvíli bude vypadat. Jestli bude třída Neon prostě \Nette\Neon, nebo \Nette\Classes\Parsers\Neon\Neon, nebo \Nette\Neon\Neon, …. Stejně si na začátku souboru udělám use …, nebo mi to IDE napoví. Samotný fakt, že se něco přejmenuje, mi vážně tolik nevadí. Nevím, jaký konkrétně k tomu byl důvod. Jestli to bylo víceméně akademické, nebo to mělo nějaký hlubší smysl. Stále se to ale provádí v alpha verzi a až vyjde stable 2.0, tak předpokládám, že do 3.0 se zpětná kompatibilita u ničeho porušovat nebude. Výjimkou je samozřejmě nějaká vývojová větev.

Editoval Petr Motejlek (11. 2. 2011 12:12)