Moda v pojmenování nebo nešvar?

David Matějka
Moderator | 6352
+
+5
-

@Polki jestli navrhuješ aplikaci tak, že máš všude rozhraní pro „co kdyby“, tak je to akorát over engineered. Lepší přístup za mě je, že budu mít třeba službu ArticleSearcher, která bude rovnou implementace hledání třeba v postgresu. a najednou se rozhodnu, že potřebuju mít i implementaci pro elastic. Tak z ArticleSearcher udělám interface, původní implementaci pojmenuju PostgtreArticleSearcher a vytvořím ještě druhou pro elastic. Změním DI konfig a v kódu jsem nemusel dál změnit ani řádku.

Milo
Nette Core | 1175
+
0
-

dsar napsal(a):
In my opinion a final class Translator doesn't mean anything. Translator using what source? The same for the Authenticator, it authenticates against what? An implementation that got a so simple name doesn't give a so much important information, so it looks like something abstract ;-)

In two different projects I have NeonTranslator and DatabaseTranslator, just by looking at the name I know where the class takes data.
Otherwise the only way is by looking at source code. Yes, because in PHP we can do that. What if I have translator.so/translator.dll? With an hex editor or disassembler? :-)

@dsar If you have only one translator in the app (99 % of my applications), it is right to name it just like App\Translator. Why would you need to name it NeonTranslator? When you want, you can change internal implementation of it to use database. “No one” cares how it works inside. With your naming pattern, you have to refactor application.

Of course, if you have multiple translators in the app for some reason, specific naming if absolutely OK.

Anyway… I worte how I use it. It is absolutely smooth for me. If you prefer specific naming, it is OK too. This discussion started about I prefix and that's different story.

Pavel Janda
Člen | 944
+
+2
-

Snažil jsem se na začátku diskuze naznačit něco objektivně, ale trochu mi to ujelo.

Nejde zdaleka o to, jestli se bude v Nette interface prefixovat nebo ne. Jde o to, jak moc se bude chtít Nette odlišovat od zbytku světa. Mám Nette fakt rád, ale postupně od něj začínám upouštět, protože:

  • Svět používá PSR-7 (ať už se jedná o nejpoužívanější php frameworky – Symfony, Laravel nebo knihovny – guzzle), Nette ne
  • Svět světa používá yml (pozor, nejen PHP, ale i ostatní jazyky), Nette Neon
  • Svět používá PSR-4, Nette má v sandboxu (což by měl být ukázkový příklad pro nováčky) Robot Loader

Můj point – je opravdu pravda, že Nette žije v době „post-monolitické“? Opravdu lze tak jednoduše skládat novou aplikaci z různých kousků různých frameworků, knihoven a počítat u skládání a vyměňování s Nette?
Nebo se Nette stále víc a víc odslišuje od zbytku světa? Není tohle další malinký příklad odlišení se?

Chápu, může to být akademicky správně. Ale není to na úkor použitelnosti v běžném životě?

A fakt mám Nette rád.

Howgh

Kamil Valenta
Člen | 332
+
+5
-

Milo napsal(a):

Padají tu argumenty, že je to na první pohled vidět z názvu souboru. A to v jakých situacích koukáte na názvy souboru?

Jak už jsem psal, třeba v tabech IDE. Mám v jednom tabu samotnou classu, v druhém tabu mám její interface. Na první klik trefím správný tab. Pokud nebudou rozlišeny ve filename, musím si zobrazit celou path (zdržuje) nebo to tipnout (a třeba se netrefit).

Dalším příkladem mohou být situace mimo vývoj, kdy nemám IDE a jsem třeba narychlo jen na terminálu, v mc apod.

Hodně se tu řeší, proč by měly prefixy v názvu být, ale trochu zapadlo, proč by tam být neměly. Stále mne zajímá, čemu tolik vadí. Důvody, že „IIdentity“ vypadá jako překlep považuju za uměle zkonstruované…

Mabar
Člen | 360
+
+3
-

@PavelJanda
PSR-7 – Symfony má oficiální port, ale http foundation jej nepoužívá a podle tweetů od Nicolase a Fabiena si troufnu říct, že ani nikdy používat nebude. Zapracovat immutable value objecty namísto mutable služeb není jen tak.

yml – kupříkladu Symfony nedávno migrovalo své DI configy na php metody. Což je imho pro wiring aplikace krok správným směrem, jelikož je PHP-specific a může benefitovat z flexibility programového zápisu a type safety.
Pro obecné configy je to imho úplně jedno. Ani jeden nemá napovídání a validaci, xml ano. Neon má oproti yml bonus v podobě méně magie a podpoře tabů. yml má výhodu v tom, že je známější a language independent, ale imho to nevýhody a potřebu migrace nevyvažuje.

S PSR-4 souhlasím a tady bych se opět opřel o argument s IDE – PhpStorm umí správný namespace vytvořit podle nastavení v composer.json. S hloupým editorem a pro méně zkušené je však robotloader obrovská pomoc – v tomhle případě už nezáleží na tom, co přinese víc užitku a nezávislost na IDE?

@KamilValenta
Pro rozlišení v tabech stačí mít například Identity a DefaultIdentity (pokud pro výchozí implementaci neexistuje lepší název vysvětlující, čím je specifická). Je to přesnější, než Identity a IIdentity a rozhodně si toho v tabu všimnu snadněji. Dokud nemáme kombinaci třídy a interface jako v Dartu, tak je identický název dost matoucí.

Ono to není o tom se prefixů a suffixů zbavit, ale používat takové, které mají větší smysl a přidanou hodnotu (tzn že nejsou duplikátem metadat). Když uvidíš ve složce Identity, BaseIdentity, StringIdentity a IntIdentity – není moc prostoru pro zmýlení se.

Editoval Mabar (11. 1. 15:41)

Kamil Valenta
Člen | 332
+
+1
-

@Mabar
A proč tedy nemohu mít BaseIdentity implementující IIdentity a využívající TIdentity?
Čemu vadí, že místo n možností, jak poznat, že jde o interface či traitu, jich budu mít n+1?

F.Vesely
Člen | 362
+
0
-

Prijde mi, ze se tu vetsina lidi bavi o tom, jestli ve svem kodu je lepsi mit prefixy nebo sufixy a ne ve frameworku Nette. Nebo to mi chcete rict, ze s interfaces Nette pracujete tolik casu a furt je hledate?

Polki
Člen | 291
+
0
-

F.Vesely napsal(a):

Prijde mi, ze se tu vetsina lidi bavi o tom, jestli ve svem kodu je lepsi mit prefixy nebo sufixy a ne ve frameworku Nette. Nebo to mi chcete rict, ze s interfaces Nette pracujete tolik casu a furt je hledate?

Nejde o hledání jde o to, že celý kód by měl být nějak jednotný. No a tuším někdo psal, že to jak to vypadá ve FW určuje směr dalšího vývoje. Nováčci se podle toho řídí atp.

Tím pádem by mělo být názvosloví jednotné v rámci celé aplikace a pokud začneme s tím, že FW to dělá nějak aplikace jinak a další kód (například komponenty) trochu jinak, tak se dostáváme do světa, kde vládne chaos a nedá se v tom vyznat. Tedy když FW udělá takový krok, tak to znamená pro komunitu přepnout se na tento nový způsob uvažování.

Pokud potom nebude sjednocený standard pro tento návrh, tak se dostaneme k tomu, že ve větších aplikacích, které neběží na jednom serveru ale pomocí microservices a na každou microservicu se použil jiný FW podle toho, jaká technologie byla nejvhodnější pro daný úkol, tak se dostáváme k tomu, že ten, kdo se o to stará když bude muset upravit něco v jiné microservice, tak to bude nadlidský úkol, jelikož každá by si to fičela po svém a vyznat se v tom co kde co jak používá je peklo. A to ještě když by FW fičel jinak než zbytek kódu v té microservice. To by se potom muselo kontrolovat, pořád co se kde jak dělá.

Prostě FW určuje proud.

Kamil Valenta napsal(a):

Hodně se tu řeší, proč by měly prefixy v názvu být, ale trochu zapadlo, proč by tam být neměly.

O tom říkal David, že napíše článek tuším.

Vzhledem k tomu, že je Nette prý komunitní projekt, tak bych udělal hlasování a nechal rozhodnout komunitu.

David Matějka
Moderator | 6352
+
+1
-

Vzhledem k tomu, že je Nette prý komunitní projekt, tak bych udělal hlasování a nechal rozhodnout komunitu.

skvělý nápad! navrhuji rozdělit hlasovací práva třeba dle zásluh

Polki
Člen | 291
+
+1
-

David Matějka napsal(a):

Vzhledem k tomu, že je Nette prý komunitní projekt, tak bych udělal hlasování a nechal rozhodnout komunitu.

skvělý nápad! navrhuji rozdělit hlasovací práva třeba dle zásluh

Tak to by mě zajímalo, jak to chceš udělat :D Kdo má větší zásluhu? Člověk, který vydal více commitů, nebo člověk, který přivedl více podporovatelů (donate)? Nebo člověk, který za Nette bojuje a prezentuje ho všude, chodí učit programování a učí to na Nette, aby mu dělal reklamu?

Jak zjistíš takovou statistiku a kdo z nich má mít větší podíl na hlasování?

Editoval Polki (11. 1. 18:03)

Toanir
Člen | 57
+
+1
-

A co nějaký jednoduchý dotazník kde by mohli členové zmínit prvky které jsou důležité a ostatní by k tomu hlasovali, zda-li to také shledávají důležitým anebo to naopak shledávají nepodstatným.

Závěrečné rozhodnutí by bylo na správcích repozitářů, jako doteď. Tedy s tím že můžou a nemusí přihlédnout na názory.

Toanir
Člen | 57
+
0
-

Ad původní téma a škatulkování kódu, baví mě do názvu dávat jen to, co skutečně vystihuje obsah třídy/rozhraní/traity. Čekám, že bude mít metodu translate(...) a podle toho se k němu chovám v místě užití – tam mě ale nezajímá jestli je to třída nebo rozhraní a proto ani v názvu nepotřebuju žádný uvozování nebo „upřesnění“.
Tj Translator má imho stejnou informační hodnotu jako TranslatorInterface a spíš mi v názvu redundance typu překáží (už je to uvedeno v klíčových slovech v definici)

Líbí se mi, jak to shrnul David zde. Tj když se pak v celým projektu starám jen o jeden překladač, může to být třída. Kdybych ale potřeboval rozlišovat implementace, z třídy extrahuju rozhraní a vytvořím třídy, který se jmenujou podle toho, jakým způsobem toto rozhraní implementují. Tedy třeba SimpleTranslator, MysqlTranslator.
Jak je Translator implementovaný mě pak ale zajímá pouze v momentě konfigurace v DI, nikoliv v místě užití.

Kamil Valenta
Člen | 332
+
0
-

David Matějka napsal(a):

Vzhledem k tomu, že je Nette prý komunitní projekt, tak bych udělal hlasování a nechal rozhodnout komunitu.

skvělý nápad! navrhuji rozdělit hlasovací práva třeba dle zásluh

Nezlob se, ale pokud to nebylo myšleno jako vtip (protože já se zasmál), tak by bylo hodně smutné, že se škatulkuje na hlasovací práva, nadpráva, lidi, nadlidi.

Myslel jsem, že rovnější rovnost upadla s minulým režimem.
Pokud je pro Nette rozhodující a jediné kritérium autorství tříd, tak David mohl zůstat u one-man-show…

Mabar
Člen | 360
+
0
-

@Polki

ve větších aplikacích, které neběží na jednom serveru ale pomocí microservices…

Tohle je naprostý argumentační faul. S vhodnou strukturou můžeš psát jako monolit aplikaci o desetitisících tříd, na to nepotřebuješ microservices. Microservices se vytvářejí primárně proto, že aplikaci vyvíjí více lidí ve více jazycích, ne kvůli velikosti aplikace. Jestliže nedovedeš navrhnout dobře monolit, tak u microservices zakopneš tím spíš. Navíc vzhledem k tomu, že se mikroservices píšou v různých jazycích spíš narazíš na to, že v každém jazyku jsou ty prefixy a suffixy jiné – například v javě bys měl Identity a IdentityImpl. V jiných jazycích je to zase jinak.

Nette dřív používalo prefixy I u interface, pro abstract převážně Base a pro trait (afaik) nikdy nic.

Symfony má Interface suffix a Trait suffix, u abstract občas Abstract prefix (AbstractAdapter v cache), občas Base prefix (BaseNode v config), a vzácně vůbec nic (Command v Console, který bez přetížení metody execute nefunguje a měl by tedy být abstraktní).

Laravel má například tyto traity: ManagesFrequencies, HasParameters, Authenticable, AsPivot. Polovina jich má suffix able. Našel jsem čtyři traity se suffixem Trait – ConfirmableTrait, ResponseTrait, CapsuleManagerTrait a RouteDependencyResolverTrait.
Abstraktní jsou například AbstractHasher, Broadcaster, CacheEvent. Interface PrunableBatchRepository, Queue, ResponseFactory, ConnectionInterface… Jestliže to téměr bez duplikace metadat jde v nejpopulárnějším php frameworku, proč by to nešlo i v Nette? Proč má jít Nette proti proudu? ;)

Nette udělalo krok k implementaci nezávislé na frameworku a jazyce. Ať to můžeš mít ve všech microservices stejně ;)

Kamil Valenta
Člen | 332
+
0
-

Plánuje se z výjimek odstranit suffix „Exception“?

David Grudl
Nette Core | 7417
+
+1
-

@PavelJanda prosím, nebourej vlákno o jmenných konvencích.

@KamilValenta

Hodně se tu řeší, proč by měly prefixy v názvu být, ale trochu zapadlo, proč by tam být neměly.

Důvodů je několik. Historický: je to poslední pozůstatek maďarské konvence od které se zcela opustilo. Tak jako jsme opustili datový typ na začátku proměnné, podtržítko na začátku privátní property, tak je přirozené opustit i I na začátku rozhraní.

Akademický důvod: pokud si funkce vyžádá proměnnou Foo $foo, tak znám její rozhraní a vím vše co potřebuji. Nemělo by mě zajímat jestli je Foo třída nebo rozhraní. Lépe řečeno, všechny důvody proč bych to mohl chtít vědět jdou proti čistotě návrhu a smyslu OOP.

(Samozřejmě v praxi je rozdíl v tom, že objekt může mít public properties. U interfaces je možné je deklarovat phpDoc anotací.)

Praktický rozdíl: při vývoji aplikace se stává, že potřebuju víc implementací původně jedné třídy. Najednou mi nestačí třída App\Translator pro statické texty a potřebuju ještě translator pro editovatelné texty. Správnou cestou je z App\Translator udělat interface, původní translátor přejmenovat na StaticTranslator a vytvořit nový EditableTranslator. Všechny typehinty v aplikaci zůstávají funkční, v kódu se nic nemění, jen tam pomocí DI šoupnu jinou instanci.

(Než jsem to dopsal tak to napsali jiní :)

Mabar
Člen | 360
+
0
-

@KamilValenta Serióně teď to, že každý uživatel nemá právo kecat do vývoje srovnáváš se socialistickou diktaturou ignorující lidská práva? Něco srovnatelného v pátek udělali demonstrantni v Praze, měli Davidovu hvězdu s nápisem „neočkovaný“ :) A to je hodně smutný.

David Grudl je držitel autorských práv, nejaktivnější autor a maintainer jak kódu, tak i dokumentace. Ostatní nemají tolik commitů ani řádků kódu v Nette dohromady, co má on sám. Do počtu přednášek, školení a článků je jistojistotě taky nejaktivnější. Co tobě konkrétně dává právo stěžovat si na to, že rozhoduje David?

O Laravelu rozhoduje Taylor Otwell, o Symfony Fabien Potencier a Nicolas Grecas, o Tailwindu Adam Wathan… všechno jsou to projekty jednoho, či několika málo lidí. V PHP abys měl hlas musíš nejdříve napsat smysluplnou feature a být schválen členy. U jazyků a projektů vlastněných firmami si můžeš o hlasovacím právu nechat jen zdát.

A tohle jsou všechno záležitosti kapitalismu. Být to komunismus, jak naznačuješ, tak Davida mohl o Nette taky připravit někdo mocnější, kdo o něm ví velký prd.

David Grudl
Nette Core | 7417
+
+1
-

Kamil Valenta napsal(a):

Plánuje se z výjimek odstranit suffix „Exception“?

Ne, protože v názvu každé třídy musí krom specifičnosti (Deprecated) být i obecnost (Exception).

Ale výjimkou jsou attributy :)

Jinak Nette samozřejmě není demokracie, vůbec nechápu jak tě to mohlo napadnout, ale hlasuje se o něčem docela často:

https://twitter.com/…446182551567
https://twitter.com/…027406049283
https://twitter.com/…175638802434
https://twitter.com/…926941827073
https://twitter.com/…538570289159
https://twitter.com/…316388057089

Kamil Valenta
Člen | 332
+
0
-

Mabar napsal(a):

že každý uživatel nemá právo kecat do vývoje

Nepodsouvej mi prosím něco, co jsem neřekl.

Něco srovnatelného v pátek udělali demonstrantni v Praze, měli Davidovu hvězdu s nápisem „neočkovaný“ :) A to je hodně smutný.

Ne, to vůbec srovnatelné není.

>

Co tobě konkrétně dává právo stěžovat si na to, že rozhoduje David?

Ocituj mi prosím, kde si na něco takového stěžuji, nebo se uklidni.

Já jsem reagoval na @DavidMatějka, nebyl jsem ani ten, kdo navrhoval hlasování nebo ho schvaloval. Vyjadřoval jsem se jen k tomu, že hlasování má být rovné, nebo žádné. To, co jsi popsal, znamená, že by v tom hlasování mohl hlasovat jen a pouze DG. A já neříkám, zda by to bylo dobře nebo špatně, jen že by to byla one-man-show.

Kamil Valenta
Člen | 332
+
0
-

David Grudl napsal(a):

Jinak Nette samozřejmě není demokracie, vůbec nechápu jak tě to mohlo napadnout

Znovu: nepsal jsem nic o Nette jako demokracii, ale o pohledu na jeden hlas. Předpokládám, že na twitteru 1 uživatel = 1 hlas.

Nikomu ani neodpírám možnost zavrhnout vítěze ankety na twitteru, stejně jako je tomu u schvalování PR.
Nechápu, proč diskuze sklouzává, ale prosím, čtěme pozorně kdo co napsal.

Mabar
Člen | 360
+
0
-

Myslel jsem, že rovnější rovnost upadla s minulým režimem.

Povídej, co jsi tím myslel? Když nečekáš demokratickou rovnoprávnost? Tedy „právo kecat do vývoje“, jak jsem napsal já.

že se škatulkuje na hlasovací práva, nadpráva, lidi, nadlidi

Tady si stěžuješ. Ne konkrétně na Davida, ale čekáš rovnoprávnost. Vždycky je nějaké škatulkování a má často dobré důvody. Co přesně je teda špatně v tomhle případě?

To, co jsi popsal, znamená, že by v tom hlasování mohl hlasovat jen a pouze DG

To zrovna ne. Jen to má být právě on, kdo na hlasování přistoupí (což dělá často, i když ne systémově) a kdo určuje pro hlasování pravidla.

Znovu: nepsal jsem nic o Nette jako demokracii, ale o pohledu na jeden hlas.

Psal jsi o minulém režimu. Že všichni jsou si rovní, ale někteří rovnější. To je komunismus. A čekal jsi od toho něco jiného. Tedy dost pravděpodobně demokracii. Jestli jsi očekával kapitalismus, tak není co řešit, protože ten tu právě teď je :)

Editoval Mabar (11. 1. 19:27)

Kamil Valenta
Člen | 332
+
0
-

David Grudl napsal(a):

Kamil Valenta napsal(a):

Plánuje se z výjimek odstranit suffix „Exception“?

Ne, protože v názvu každé třídy musí krom specifičnosti (Deprecated) být i obecnost (Exception).

https://www.nikolaposa.in.rs/…-convention/#…

David Grudl
Nette Core | 7417
+
+11
-

Prosím STOP diskusi o komunismu a rovnoprávnosti, díky.

David Grudl
Nette Core | 7417
+
0
-

@KamilValenta mám to chápat tak, že navrhuješ zrušit suffix u výjimek? Je to trošku podobné jako attributy, kde ho Nette nepoužívá, tak zkus téma otevřít a získat podporu.

Polki
Člen | 291
+
0
-

David Grudl napsal(a):

Ne, protože v názvu každé třídy musí krom specifičnosti (Deprecated) být i obecnost (Exception).

Proč musí? Jeho otázku zcela chápu. Pokud není třeba informace o tom, jestli to je interface, protože ten kdo jej používá to nepotřebuje vědět a ten kdo jej implementuje to ví, tak proč je třeba přidávat exception? Ta věta platí pořád stejně.

Ten kdo jej používá to nepotřebuje vědět (díky slovu throw, které může být jen u exceptions je to jasné) a ten kdo jej implementuje to ví (dědí z Exceptions, nebo implementuje Throwable).

Z tohoto je patrné, že ta otázka musela přijít.

Taktéž se může objevit otázka, proč nazýváme třídy/rozhraní/traity/metody/proměnné pomocí CamelCase a proč je u tříd/rozhraní/trait První písmenko názvu vždy velké a proč u proměnných/metod je vždy malé. Toto taky vzniklo proto, aby se rozlišilo na první pohled, co je třída (datový typ), co je metoda a co je proměnná.
Otázka zní, proč od toho taky neupustíme, nebo proč se to v PHP vůbec zavedlo, když v PHP mají proměnné na začátku jasně specifikovaný znak $?

Tak jako jsme opustili datový typ na začátku proměnné, podtržítko na začátku privátní property

Setkal jsem se s Javisty. Ti by tě za tohle hnali. Dodnes se používá v Javě u třídních proměnných prefix ‚__‘ jelikož se dají volat i bez this. a bez prefixu by se to bilo s lokálními proměnnými uvnitř funkcí. Dovolil jsem si jednou napsat kód bez nich a byl jsem linčovaný až až :D U PHP je to nesmysl, jelikož by se to pletlo s interním PHP způsobem zápisu (__DIR__, __construct …)
A hodně C# zase pořád používá datové typy na začátku proměnných aby věděli o co jde. Například: btnSend, btnCalculate, tbName (tb jako TextBox), tbSurname, tbPhone
Pak když hledají textbox, tak prostě do vyhledávání napíšou tb a vyberou si.

Nehledě na to, že od většiny věcí, o kterých píšeš, že se od nich upouští, se upouští z jasného důvodu. Například u PHP mělo ono podtržítko význam privátní proměnné, jelikož tehdy nemělo PHP modifikátory přístupů, takže se muselo nějak určit, že to je privátní proměnná. A na to se použilo podtržítko. V momentě nástupu PHP 5.0 kdy se modifikátory přístupů zavedly a tedy bylo možné psát ‚private $promenna‘ začalo podtržítko postrádat smysl, protože určení jestli je něco privátní nebo ne se již dělá jinak. Zajímalo by mě, jaký podobný posun se v PHP stal, aby interfaces nemusely mít v názvu předponu/příponu. Jak jsem psal předtím. Pokud se zavede přímo v PHP něco jako ‚znásilněná vícedědičnost v dartu‘ (implicitní interface) pak se interface a třída ‚zhroutí‘ do jedné a té stejné věci a potom nemá smysl to rozlišovat. Do té doby…

Editoval Polki (12. 1. 2:16)

Polki
Člen | 291
+
-2
-

Kamil Valenta napsal(a):

Nechápu, proč diskuze sklouzává, ale prosím, čtěme pozorně kdo co napsal.

To bych vůbec neřešil :D Hodně lidí zde nedává pozor a domýšlejí si něco, co není specifikováno. Asi málo brali výrokovou logiku v matematice :D

Spíš mi přijde, že se tu všechny argumenty překrucují sem a tam jak se komu chce.

Kamil Valenta
Člen | 332
+
+2
-

David Grudl napsal(a):

@KamilValenta mám to chápat tak, že navrhuješ zrušit suffix u výjimek? Je to trošku podobné jako attributy, kde ho Nette nepoužívá, tak zkus téma otevřít a získat podporu.

Ne, já to nenavrhuji. Jen se ptám, protože by mi to přišlo logické v duchu dosavadní argumentace, protože to splňuje vše, co bylo uváděno u trait či rozhraní. Došlo by ke zkrácení, že jde o Exceptionu je zřejmé z kontextu kódu a Nette by dle uvedeného článku nebylo první, kdo by to z názvu vypustil.

Já jsem zastáncem IIntefaců, TTrait a ExampleException.

Chápu příklad s EditableTranslator, jen se mi nezdá, že by někdo refaktoroval ručně.

David Grudl
Nette Core | 7417
+
0
-

Proč musí? Jeho otázku zcela chápu. Pokud není třeba informace o tom, jestli to je interface, protože ten kdo jej používá to nepotřebuje vědět a ten kdo jej implementuje to ví, tak proč je třeba přidávat exception? Ta věta platí pořád stejně.

Protože něco jiného jsou jazykové konstrukce (třídy, rozhraní) a něco jiného konkrétní typy tříd (presentery, výjimky, …). Pravidlo se specifičností/obecností se vztahuje pouze na konkrétní typy tříd.

Ten kdo jej používá to nepotřebuje vědět (díky slovu throw, které může být jen u exceptions je to jasné) a ten kdo jej implementuje to ví (dědí z Exceptions, nebo implementuje Throwable).

Je to tak, proto dává smysl v tomto konkrétním případě od pravidla případně upustit. Jak už jsem tu několikrát psal, je to ze stejných důvodů i případ atributů.

Ne, já to nenavrhuji. Jen se ptám, protože by mi to přišlo logické v duchu dosavadní argumentace, protože to splňuje vše, co bylo uváděno u trait či rozhraní.

Traity z toho úplně vynechme, z hlediska OOP stojí jinde. Jinak co píšu výše.

David Grudl
Nette Core | 7417
+
+2
-

Chápu příklad s EditableTranslator, jen se mi nezdá, že by někdo refaktoroval ručně.

O to vůbec nejde, jestli to nahradí editor. Point je jinde.

  • V jednom případě zůstane celý kod stejný, jen se tam pošle jiná instance.
  • Ve druhém případě se u všech typehintů doplní suffix Interface a pošle tam jiná instance.

Otázkou je, jaký smysl ta změna má z pohledu toho měněného kódu? Rozhraní se nezměnilo. Probublává tam dokonce pořad vlastně stejný objekt. Proč by najednou ten uživatelský kód měl používat místo Foo nové FooInterface?

OOP nám dává možnosti objekty nahradit jinými se stejným rozhraním, třeba potomky, nebo implementacemi stejného interface, bez nutnosti něco měnit v uživatelském kódu. To je prazáklad. Kvůli tomu dodržujme pravidla LSP apod. Když ale najednou vznikne nutnost něco kvůli tomu hromadně přejmenovat v kódu, tak to jde proti smyslu.

Polki
Člen | 291
+
0
-

David Grudl napsal(a):

Otázkou je, jaký smysl ta změna má z pohledu toho měněného kódu? Rozhraní se nezměnilo. Probublává tam dokonce pořad vlastně stejný objekt. Proč by najednou ten uživatelský kód měl používat místo Foo nové FooInterface?

To je hodně dobrá otázka. Líbí se mi. A máš pravdu. Protože vlastně na tom jak to je nazvané nezáleží. Kód se bude chovat stejně.

Odpověď na otázku je však stejná jako ta, proč se vlastně vymysleli jazyky, které mají proměnné pojmenované jinak než EAX, EBX, ECX atd. Kódu jsou tyto názvy úplně jedno klidně můžou být proměnné a třídy pojmenovány A, B, $c, $d. (PŘEHLEDNOST)

  1. Je to pro přehlednost programátorů/reviewerů atd. Když kouknu v gitu na nějaký PullRequest, tak tam mi ide okamžitě nenapoví, jestli se jedná o interface či ne a když chci vidět jak to člověk použil, jestli dobře a podle politiky firmy, tak to musím rozklikávat a hledat. Pokud tam ta specifika nejsou, tak je to matoucí.
  2. Další důvod už jsem psal. Pokud udělám komponentu a poté po mě projekt převezme někdo jiný a bude potřebovat komponentu překopírovat jinam a ve formuláři třeba uvidí v konstruktoru továrny toto: __construct(FormProcessor $fp), přičemž soubor s ‚FormProcessor‘ bude ve stejné složce jako továrna, tak nad tím nebude přemýšlet a prostě to celé zkopíruje a pak se bude divit, že mu to hlásí, že ta třída neexistuje. Přičemž nikdy neexistovala ale to on neví, protože hned z názvu nevidí, že to je rozhraní. Zatímco pokud se do názvu dá i to blbé I- tak ten, kdo bude komponentu kopírovat rovnou hned vidí, že tam je použito rozhraní a aby mu to fungovalo, tak jej musí implementovat.
  3. Na třetí jde o to co jsem psal a čím mě odbyl Matějka. Jasně napíšu třídu, když je potřeba další, tak udělám z třídy rozhraní a pak vytvořím dvě další třídy, které budou toto rozhraní obě implementovat a tedy měním jen rozhraní/přepisuju 2 třídy tedy celkem 3 úpravy, přičemž jsem se při změně více napsal, ale méně chyb je možno udělat pokud nevím, co je interface a co class. Pokud ale bude nutnost přidat ještě třetí implementaci, tak nastává úplně ten stejný problém, který jsem popsal předtím a to ten, že člověk napíše implementaci, ale bude muset hledat, co je interface, pokud vůbec bude na první pohled vědět, že má nějaký interface použít, když nebude nikde uvedeno, že jej používá (až na implements ve starých třídách).
  4. V microservicách (o kterých jsem nikdy neřekl, že je NUTNÉ je použít pro velké aplikace) s vícero různými microservicami nastanou nekonzistentnosti podobné tomu, když máte seznam účastníků, na něm sloupeček jméno vedle sloupeček příjmení a pak hromady prázdných řádků a potřebujete aby to každý účastník vyplnil a v půlce lidi přestanou číst záhlaví a budou do prvního vyplňovat příjmení a do druhého jméno a ti kteří jsou zvyklí naopak tak naopak, když to pak kontrolujete a zadáváte někam, tak zjistíte, že to každý udělal jinak a musíte krom toho kdo tam byl kontrolovat i jak to napsal a co pak uděláte třeba se jménem ‚Petr Tomáš‘? Jak se pozná, kdo je kdo? Stejné nekonzistentnosti nastanou i zde. O to horší to bude když nastanou takové nekonzistentnosti v Monolitu. V Microservicách to ještě jde, když se o každou stará jiný tým, ale v monolitu je to horší. Přijde nováček jinak naučený udělá nějak práci a nebudou domluvení a pak jsou s tím akorát problémy.

A dá se pokračovat…

Naproti tomu důvody proč to nedělat:

  1. Používalo se to dřív a nejsme přece neandrtálci z pralesa.
  2. Prostě to můžeme vynechat a program pořád poběží stejně tak proč ne?

Jsou podle mě dost chabé důvody proč to vynechat. S těmito důvody můžeme třeba vynechávat odřádkování v kódu. Jestli tam je, nebo není no používá se to od začátku a přece nejsme neandrtálci ne tak se posuňme a odřádkování zahoďme pišme kódy na jeden řádek. Přece i bez odřádkování poběží program pořád stejně a tomu kódu je úplně jedno, jestli tam to odřádkování je, nebo není. To že to zhoršuje orientaci a čitelnost je přece opominutelný argument. Můžeme rovnou psát JS kódy v minifikované verzi ne?

S radostí čekám na článek, kde budou nějaké opravdu podložené a pádné důvody k tomu, proč to tak nedělat.

Editoval Polki (11. 1. 20:38)

Toanir
Člen | 57
+
-6
-

Lol.

David Grudl
Nette Core | 7417
+
0
-

Odpověď na otázku je však stejná jako ta, proč se vlastně vymysleli jazyky…

Není. V restauraci, kde si kupuju svou oblíbenou pizzu (MyFavoritePizza $pizza) udělali rekonstrukci. Ale dostávám úplně stejnou pizzu. Jako roky předím. Proč si mám já ve svém bytě vyměnit obrazy?

Říkáš kvůli přehlednosti?

U mě doma se ale nic nezměnilo, pizza se nezměnila a co se děje v restauraci mě nemusí zajímat.

Možná fundamentálně jinak chápeme smysl OOP.

S těmito důvody můžeme třeba vynechávat odřádkování v kódu.

Tohle pro mě už není seriozní diskuse, sorry.

David Grudl
Nette Core | 7417
+
0
-

V momentě, když v rolišuješ mezi třídou a rozhraním v typehintu, je úplně jednoznačně lepší mít rozhraní s prefixem/suffem. O tom žádná.

Polki
Člen | 291
+
-1
-

David Grudl napsal(a):

Není. V restauraci, kde si kupuju svou oblíbenou pizzu (MyFavoritePizza $pizza) udělali rekonstrukci. Ale dostávám úplně stejnou pizzu. Jako roky předím. Proč si mám já ve svém bytě vyměnit obrazy?

Tohle přirovnání je trochu mimo.

Obrazy u mě doma nemají co dělat s tím, jakou jím pizzu. Jestli používáš vzhled tvojí oblíbené pizzerie na to jaké obrazy ti visí doma, tak proti tomu nic nemám. Ale je to stejné jako by jsi řekl, že na tom jaká je použitá db vrstva závisí to, jaký použiješ html tag pro prvek s ID ‚abcd‘
Důležité je, když za tebou někdo přijde, tak aby jsi mu byl schopen říct, že máš rád třeba Hawai pizzu, která je udělaná přesně podle toho a toho daného postupu (interface) a tedy ten člověk bude vědět, že když je ta pizza nejlepší, tak že pokud ji v jeho městě v jakékoliv pizzerii dělají stejně, tak bude nejlepší i u něj, nebo že je nejlepší, protože to dělá tato konkrétní Pizzerie a ta to dělá tak jedinečně, že to nikdo jiný takto neumí (class), takže to že ty jsi z Brna a on z Prahy pro něj znamená to, že pokud chce podle tebe nejlepší Pizzu, tak si musí zajet do Brna. Jasně že tobě je to jedno jestli dělají postup nebo jde o konkrétní pizzerii. Důležité je to pro ostatní, kteří to budou chtít dělat stejně. Tedy pro jakékoliv budoucí úpravy kódu.

Když chceš přirovnání k pizzerii tady je:
Mám pizzerii, kde je kuchyň a jídelna:

class Kitchen {}
class DiningRoom {}

kuchyň potřebuje číšníka a kuchaře:

class Kitchen {
    public function __construct(
        private Cooker $cooker,
        private Waiter $waiter,
    ) {}
}

podobně jídelna potřebuje číšníka…
pak budou ještě nějací CookerPepa a WaiterRobin… kteří implementují jak se má číšník a kuchař chovat (konkrétní implementace)

Teď tu pizzerii koupí jiný majitel a ve smlouvě bude napsáno, že kupuje restauraci, která obsahuje kuchyň, jídelnu, číšníka a kuchaře (Kitchen, DiningRoom, Waiter, Cooker). Brzy se bude kupující velmi divit, že nemá personál. A bude se divit oprávněně. Protože ve smlouvě nikde nestálo, že nekupuje opravdového číšníka a kuchaře, ale jen návody, jak mají pracovat v dané restauraci.

Ano zákazníkovi je jedno, že se změnil majitel. Je mu jedno i že majitel měl problémy díky tomu, že si člověk před ním věci nazval špatně a musel najmout úplně jiný personál. Důležité pro zákazníka je, že dostane stejnou pizzu jako vždy, protože je dělaná podle stejného návodu (Cooker).

Ale celé toto špatné nazvání znamená jediné. Kupující koupil zajíce v pytli protože nevěděl díky špatnému názvosloví co doopravdy kupuje, nejspíše i přeplatil, protože myslel že kupuje vše už hotové a ne jen část (nutnost doimplementovat chování – strávený čas a větší výdaje i když jsme mysleli že to je hotovo) a v neposlední řadě problémy se zjišťováním proč lidi nepřišli do práce když to koupil i s nimi (soudy a tahanice – musím zjišťovat kde je chyba a proč neexistují třídy, když jsem je zkopíroval).

Proč když si koupíme skříň z jedné nejmenované Švédské společnosti například, tak máme v balení:

  1. návod, jak tu skříň seskládat
  2. návod, jak tu skříň používat
  3. samotnou skříň (i když její části ale to je nepodstatné)

Proč v takovém případě Návod na seskládání skříně není jednoduše nazván Montér a člověk, který provádí montáže těch skříní se nejmenuje třeba KonkrétníMotnér?
Proč návod na používání skříně (jaké metody mohu nad skříní volat – interface) se nejmenuje jednoduše Skříň a každá konkrétní skříň, která je postavená třeba v ložnici se nejmenuje LožniceSkříň, ObývákSkříň, nebo pokud se nachází dvě v obýváku, tak se nejmenují prostě KonkrétníObývákováSkříň1 a KonkrétníObývákováSkříň2???

Kvůli přehlednosti a vyhnutí se problémům.

Rád bych viděl na obsahu krabice napsáno: Montér 1ks, Skříň 1ks, KonkrétníSkříň 1ks
To každému kdo si tu skříň koupí hodně řekne.

Editoval Polki (11. 1. 22:40)

David Grudl
Nette Core | 7417
+
+2
-

Ty chápeš úplně obráceně typehint.

Pro tebe je typehint něco konkrétního. Ale typehint je naopak díra. To je prázdný prostor určitého tvaru:

obr-zek-2021-01-11-224047

V tomto kódu je Cooker díra ve vstupních dveřích do objektu, která přesně kopíruje siluetu kuchaře a jen on jí může projít:

public function __construct(
        private Cooker $cooker,
}

Typehint není kuchař, naopak. Vychází to z filosofie externismu :)

Pokud si jiný majitel koupil pizzerii a ve smlouvě měl uvedeno, že tam budou dveře pro číšníka a kuchaře a on čekal číšníka a kuchaře, tak potom měl špatná očekávání. Ale to není problém děr.


Stejně tak bude zklamán, že při koupi tohoto nedostane heslo:

public function __construct(
        private string $password,
}

Pokud se na typehint budeš dívat opravdu jako na díru, nebude mít pro tebe prefix/suffix smysl. Pokud v něm chceš vidět informaci navíc, metainformaci o uvedeném identifikátoru, takový tooltip bez nutnosti najet myší, pak samozřejmě je prefix/suffix užitečný. Problém je, že v tu chvíli chceš něco, k čemu to není zamýšlené, a co bohužel je v rozporu z primárním posláním.

David Grudl
Nette Core | 7417
+
+1
-

Idea pro kompromisní řešení:

class Kitchen {
    public function __construct(
        private Cooker/*Interface*/ $cooker,
        private Waiter/*Interface*/ $waiter,
    ) {}
}
Lukes
Člen | 67
+
0
-

Osobně bych si nikdy nemyslel, že se někdo bude zastávat maďarské notace a různého jiného prefixování. Tím už nás mučil na fakultě jeden nejmenovaný učitel a na "LUK" "PUK" (neboli levý a pravý ukazatel) jsem byl alergický. Musím uznat, že učiteli bylo přes 60 a nějaké novoty mu nebyly po chuti.

Každopádně myslím, že nad návrhem aplikace špatně přemýšlíte. Pokud chci vyvíjet nějaký PHP balíček, tak přede už z podstaty je to špatné. Protože přijde nováček a teď přemýšlí jestli má jako závislost vyžadovat ITranslator nebo Translator… Hmm nevím jak vy, ale já bych si jako nováček vybral Translator. A ano chceme předávat do služeb a business logiky rozhraní, aby se dalo případně přeimplementovat beze změn v původním kódu. Pokud to máte jako závislost v dalších balíčcích, tak je to vůbec super vydávat nové verze.

Pokud píšu například nějaký platební systém. Mám tam objekt nějaké transakce, kterou je dobré někam uložit. Tak když píšu balíček, tak nemám databázi nebo tak něco. V testech to potřebujete mockovat. Tak si vyžádám nějaký úložiště. Třeba Storage. Proč to mám pojmenovat IStorage, jen proto, že je to interface? Mě to nezajímá… Já tu Storage nechci psát. Já ani nevím kam se to bude ukádat, ale já chci prostě Storage a ať se o to postará někdo jiný. DI princip… Interface je okraj aplikace, nebo něco co není pevně dané, ale z pohledu funkcionality je to jedno. A když pak půjde kolega, který nainstaluje do projektu balíček, který jsem napsal, tak mu to zařve hej já chci implementaci Storage… On sedne a udělá DatabaseStorage, FileStorage, RedisStorage, ŠuplíkStorage a podobně.

Možná se zeptejte proč a na co jsou interface. Určitě Nette nebude nepřehledný kvůli tomu, že mám Translator a ne ITranslator.

Argumenty typu, že to tam blbě dělají ostatní, bych se vykašlal, protože jestli někdo viděl jak je napsaný WordPress/Magento/PrestaShop, tak bude rád, že může psát v Nette.

Editoval Lukes (11. 1. 23:13)

Polki
Člen | 291
+
-1
-

David Grudl napsal(a):

Ty chápeš úplně obráceně typehint.

uh… Nope nemám sílu to už pořád dokola opakovat :D

Bližší specifikace:
To, že ve smlouvě je napsáno:

Polki napsal(a):

obsahuje kuchyň, jídelnu, číšníka a kuchaře (Kitchen, DiningRoom, Waiter, Cooker).

Znamená, že reálně dostal:
soubor Kitchen.php (class Kitchen)
soubor DiningRoom.php (class DiningRoom)
soubor Waiter.php (interface Waiter)
soubor Cooker.php (interface Cooker)

Důležité je, že aniž by udělal hlubší analýzu, tak nemá jak poznat, že Waiter vlastně není číšník, ale jen nápověda na to, jak se má číšník chovat. Tím pádem kupuje zajíce v pytli. Nemá to vůbec co dělat s tím, že kuchyň očekává že v ní bude někdo vařit. Vůbec tu nepíšu o typehintech.

Stejně tak ten návod. Pokud někomu řeknu k tomuto výrobku dostaneš montéra (konkrétní papír, návod, hmatatelnou věc) ale myslím, tím, že to vlastně není motnér, ale jen rozhraní montér, tedy popis kroků, jak by měl danou věc montér smontovat, nebo co musí umět aby to dokázal… Jak to mám sakra poznat podle názvu?
Když mi někdo řekne, že k té skříni, co si chci koupit dostanu montéra, tak budu automaticky očekávat, že přijde někdo, kdo mi to smontuje a ne že dostanu návod jak na to a montéra si budu muset obstarat sám. (To, že skříň potřebuje prostě něco co ji umí složit podle toho návodu tedy asi něco co implementuje interface NávodNaSložení je v tuhle chvíli úplně jedno.)

David Grudl napsal(a):

public function __construct(
        private string $password,
}

Tedy laicky řečeno aby to pochopilo i dítě:
V tomto tvém příkladu nebudu očekávat (jako ten kdo ten kód bude chtít použít i jinde), že k tomuto kousku kódu dostanu i heslo, ale že k němu dostanu i základní datový typ string a tedy dostanu plnohodnotnou logiku která už má hotovou vnitřní implementaci, jak se má string chovat. Tedy budu očekávat, že když vezmi tento kód a zkopíruju ho do svého kódu například, tak bude fungovat, jelikož vím, že v mém kódu již něco jako string existuje. (v případě, že by byl string třída, tak bych zároveň zkopíroval i soubor se třídou string tedy nejspíše soubor String.php a tedy bych očekával, že string bude fungovat nadále bez mého dalšího zásahu (pokud není něco, co by potřeboval jako povinnou závoslost, což by mi řekla třeba TRACY)). Pokud však tvůj string bude interface, tak já se to nedozvím a zakládám si na malér.
Naopak pokud by to vypadalo takto:

public function __construct(
        private Istring $password,
}

Tak jistojistě vím, že ten soubor, co jsem s tím koupil (Istring.php) NENÍ konkrétní funkční implementace a já ji musím dodat. A vím to, aniž bych se koukal dovnitř a nemůžu v tomto případě ani očekávat že by to bylo jinak a tedy zde NENÍ prostor pro chyby.

Jsem tak trochu vysílen z toho vysvětlovat vše tak aby to pochopili všichni, takže když dovolíte, tak se již nadále tohoto nezúčastním. Stejně nevím, co dál bych k tomu dodal.

EDIT 1:

David Grudl napsal(a):

class Kitchen {
    public function __construct(
        private Cooker/*Interface*/ $cooker,
        private Waiter/*Interface*/ $waiter,
    ) {}
}

To se mi líbí. Komentáře ať si cpe kdo chce kam. To je dobrý nápad. Problém je, že kdo to bude používat bude chtít udělat CTRL+C a CTRL+V nad složkou s komponentou a nebude chtít otevírat kód a prokousávat se kódem. Většina z nich uvidí jen názvy souborů, které jsou ve složce a tedy:

ContactFormFactory.php
ContactFormProcessor.php
FormFactory.php

A pokud už z názvu souboru není zřejmé o co jde a musíme ty soubory otevírat a zkoumat abychom zjistili co to je, tak to je ten daný problém. A do názvu souboru komentář nedáš. A kdyby se to udělalo takto:
IContactFormProcessor.php obsahuje interface ContactFormProcessor {} tak jsme pro změnu porušili PSR standardy a daleko jsme se nedostali.
BTW díky namespaces můžeme udělat něco jako use IContactFormProcessor as ContactFormProcessor;, takže nemusíme řešit a v případě změny třídy za interface se změní jen namespace, který se stejně bude muset měnit, když budeme předělávat třídu na interface, abychom zachovali jednoduchou znovupoužitelnost. Takže opět nevidím důvod tam I- nedávat, když v adresářové struktuře a v názvu třídy jasně vidím, že to je interface díky názvu a ve všech třídách, kde to interface použiju to budu mít nazváno bez toho I.

Ne nadarmo kdysi jeden známý moudrý muž řekl: V programování jsou pouze 2 obtížné věci. První je poznat, kdy invalidovat Cache a ta druhá je pojmenování věcí.

Editoval Polki (12. 1. 1:04)

Kamil Valenta
Člen | 332
+
+1
-
class PresenterFactory implements IPresenterFactory

Implementace i interface jsou ve stejném adresáři. Jsem zvyklý, že název = filename.
Je rozdíl, zda budu mít v typehintu IPresenterFactory nebo PresenterFactory. A po výše citovaném refaktoringu mi do té „díry“ někdo prohodí docela jinou „kostičku“, která vůbec nemusí disponovat potřebnými metodami.

Editoval Kamil Valenta (11. 1. 23:31)

David Grudl
Nette Core | 7417
+
0
-

@Polki v pohodě, máš svá očekávání, to je v pořádku. Já třeba důležité složky prefixuju podtržítkem, aby se mi zobrazovaly jako první, vyhovuje mi to a kdyby někdo přišel s tím, abych podtržítka smazal, hodně by mi to vadilo.

Jenže je to moje specifická konvence a někdo jiný zase má úplně jinou konvenci atd. Ty očekáváš, že v Soubor.php najdeš třídu a nikoliv interface. Ale to ti nikdo nebere. Nic ti nebrání to tak dělat. Ale nemá smysl chtít po ostatních aby fungovali stejně.

Polki
Člen | 291
+
-1
-

David Grudl napsal(a):

@Polki v pohodě, máš svá očekávání, to je v pořádku. Já třeba důležité složky prefixuju podtržítkem, aby se mi zobrazovaly jako první, vyhovuje mi to a kdyby někdo přišel s tím, abych podtržítka smazal, hodně by mi to vadilo.

Jenže je to moje specifická konvence a někdo jiný zase má úplně jinou konvenci atd. Ty očekáváš, že v Soubor.php najdeš třídu a nikoliv interface. Ale to ti nikdo nebere. Nic ti nebrání to tak dělat. Ale nemá smysl chtít po ostatních aby fungovali stejně.

Mluvím z praxe. Ne z větru. Když jsme to v jakékoliv firmě zkusili, tak z toho byl větší malér než užitek.

Ve výsledku je to jedno. Ať se cesta bude ubírat kterýmkoliv směrem, tak komunita bude muset reflektovat FW.
Nicméně to co jsi napsal platí i obráceně. Když je to do teď nějak a TY případně tví kamarádi, co ti pomáhají jste se rozhodli dělat to nějak jinak (A nic vám nebrání to tak jinak dělat), tak co má z opačné strany v tvém případě smysl chtít po ostatních, aby to fungovali stejně? :)
To byla řečnická otázka odpověď je mi jedno stejně jako to jakou konkrétní instanci mi prohodíš ‚dírou‘.

Kamil Valenta napsal(a):

A po výše citovaném refaktoringu mi do té „díry“ někdo prohodí docela jinou „kostičku“, která vůbec nemusí disponovat potřebnými metodami.

A taky tím, že například máš třídu ‚UserManager‘ v namespace ‚App\Model‘, tak tím, že si nevytvoříš zvlášť rozhraní, které má nějaké jednotné namespace (například díky tomu že je ve stejné složce tak ho má stejné jak třída kde ho používáš) tak poté v komponentě, kde třídu (App\Model\UserManager) používáš při změně na rozhraní docílíš toho, že ten kdo bude chtít tvou komponentu použít v jiném prjektu, tak bude muset díky špatnému návrhu ctít tvůj namespace, takže když bude mít například úplně jinou adresářovou hierarchii s jinými Namespaces, tak bude kvůli tobě muset vytvořit dané složky a dané interfaces s danými namespaces a úplně si tak rozházet vlastní projekt. Pokud bude chtít zachovat svou původní adresářovou strukturu, tak mu nezbyde nic jiného, než otevřít všechny soubory, kde se to rozhraní používá a změnit si Namespace, na nějaký rozumný, který odpovídá jeho adresářové struktuře. Takže vlastně bude muset udělat úplně tu stejnou práci jako kdyby prostě bylo u názvu rozhraní na začátku I- a to refaktoring v půlce aplikace. A je úplně jedno, jestli se ten refaktoring dělá kvůli tomu aby se přidalo I- na začátek názvu, nebo aby se tam, kde se ten interface používá muselo všude změnit interface v USE. Jinými slovy musíš ctít Namespace původní třídy, než se z ní stal interface, nebo interface změnit. Oba způsoby jsou další komplikace.
Skóre I- vs nic

  • za refaktoring těch samých souborů je tedy 1–1
  • za znovupoužitelnost kódu beze změn a problémů s implementací 1–0

Editoval Polki (12. 1. 0:18)

David Grudl
Nette Core | 7417
+
0
-

Ať se cesta bude ubírat kterýmkoliv směrem, tak komunita bude muset reflektovat FW.

Proč??? Co tě k tomu nutí?

F.Vesely
Člen | 362
+
+6
-

@Polki Pouzivam Nette jiz nekolik let a ve svem kodu prefixy u interfacu nemam nikde. Stejne tak nemam nikde sufixy u vyjimek.

Ja vas chapu, ze kazdy preferujete nejaky styl a hajite si ho, ale jak to bude delat Nette vam prece ve vasi aplikaci muze byt ukradeny. Pouzivam hromadu knihoven a kazda to ma jinak, neridim se ani podle jedny z nich.

Šaman
Člen | 2528
+
0
-

Taky si říkám, že Nette rozhraní používám jen v několika třidách souvisejících s přihlašováním a bezpečností a tam si mohu použít alias

namespace App\Security;

use Nette\Security\Authenticator as IAuthenticator; // dříve: use Nette\Security\IAuthenticator;

class Authenticator implements IAuthenticator
{
}

a všechno pro mě bude při starém.

Pavel Janda
Člen | 944
+
+1
-

David Grudl napsal(a):

Ať se cesta bude ubírat kterýmkoliv směrem, tak komunita bude muset reflektovat FW.

Proč??? Co tě k tomu nutí?

Nikdo k ničemu nikoho nenutí. Rád bych se ale podělil o svou zkušenost – za svůj programátorský život jsem se už potkal s desítkami nováčků, které při otázce na „Proč to děláš takhle?“ odpověděli „No tak to dělá Nette Framework, tak je to určitě správně“.
Just sayin'

Pavel Janda
Člen | 944
+
+3
-

Ale pojďme toto vlákno už ukončit, začíná se tříštit.
A přiznejme si to, stejně se v PHP zas tak moc změn neděje. Co by za to dali kluci z frontendu, kdyby se jim měnilo jen názvosloví interfaců… jednou za pár let. :D

David Grudl
Nette Core | 7417
+
+1
-

Taky proto Nette tu změnu podstupuje, aby šlo příkladem. Ale k čemu nutí Polkiho?

Václav Pávek
Backer | 84
+
0
-

Docela zajímavé počtení :‑/ Mě je jedno jak to dopadne, stejně si aplikaci napíšu podle sebe tak proč někomu cpát svoji pravdu. Ale názor je potřeba říci.

Václav Pávek
Backer | 84
+
0
-

Pokud bychom se zbavili prefixů a suffixů, tak bych se chtěl optat jakou máte konvenci u trait? U urait trošku váhám, ale nejspíše jsem málo kreativní při vymýšlení názvu (popisu činnosti).

ppar
Člen | 355
+
-7
-

Vyřešen nešvar / moda https://github.com/…es-standards . Když mě nikdo nevyslyšel, poradil jsem si sám.

Editoval ppar (7. 2. 11:25)