Moda v pojmenování nebo nešvar?

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.

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
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 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 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. 2021 18:03)

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í.

@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ě ;)

@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í :)

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

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.

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/#…

@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.

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.

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 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. 2021 20:38)

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 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. 2021 22:40)

Idea pro kompromisní řešení:

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

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. 2021 1:04)

@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ě.

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

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

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.

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

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.