@Maartin s tou anotací to není úplně špatný nápad, ale kdyby to šlo bez ní, bylo by to přeci jen nejlepší – jde mi přeci taky o úsporu kódu, zjištění těch argumentů se skutečně může odehrávat podobně jako to v současnosti děláme u anotací, tam také musíme skenovat hierarchickou strukturu (a jde to )

@vsem díky za podnětné komentáře, jsem rád, že se podařilo trošku rozproudit diskusi

Dedeni bych taky neresil, nedokazu si predstavit, ze by programator nevedel kterym smerem v hierarchii se vydat – pokud tam mam dynamicky proxy, tak vim jestli se vygenerovaly k mymu interfejsu nebo k my tride. Zadny konflikty by tez nebylo treba resit, pripadne by si poresil programator kdyby si je tam nadelal – coz si tez moc neumim predstavit.

Vyhodpu oproti APT by byla prenostitelnost (to APT je treba delat pro kazdy prekladac znova a muze se bit s jinym APT) a standardizace (rozumnel by tomu i Javadoc a jmena patricne zvyraznoval).

> 4Otec: No ale dost to omezuje pouziti takovych jmen….
Me se nezda ze by to byl vubec problem, protoze tam kde bych to pouzil bych i presne vedel kam mam jit. Normalne bych to pouzil jen pro jeden druh objektu, rekneme pro entity a kdyz jsem je napsal jako tridy, tak musim u proxy jit k predkovi, atd. (uz bych se opakoval).

Vic mi vadi, ze to nepujde pouzit pro neco jako konstruktor

@com.google.inject.Inject
Article(@Named(„title“) String title, @Named(„description“) String description, Author author, Date publishedDate)

(to Named jsem schvalne pouzil jen kde je potreba), ale k tomu me vazne nic nenapada.

Mne spise vadi absence aspektu v zakladni jave a k tomu samozrejme i kontraktovaci api.

Ale ono je toho strasne moc co by v jave mohlo byt a neni tam a pritom v jinych jazycich to je. Napr. v Lispu je obdoba aspektu od sameho pocatku – tusim se to menuje hook. Na druhou stranu sem ale rad, ze je Java porad docela konzervativni. Prave z Pythonem, mam docela nepekne zkusenoti prave se zpetnou kompatibilitou, vzhledem k tomu ze dost velka cast KDE a Gnome (a utilit pro neho) je psana v Pythonu, tak sem si prosel peklem, kdyz sem nechte upgradoal na novou verzi.

Nicméně souhlasím s tebou, že nic není triviální, jak se na první zdá. Určitě by se komplikace našly. Je otázka jak problematicky jsou řešitelné. Skutečně už je v Javě dost znát ta stále narůstající koule s nálepkou zpětná kompatibilita.

Co se týká generik, tak ty přes reflexi v runtime dostupné jsou. Jen se nedostaneš na konkrétní hodnoty wildcard generik – tam máš k dispozici jen „bounds“. Viz. minulý článek.

Problem je v tom, ze tohle muze mit docela nepekne dopady a neni to az tak trivialni, takze se nedivim ze se to odklada. Protoze vzdycky tu bude reseni vyhovujici jednem a nevyhovoujici druhym. Navic tu porad existuje reseni sice ukecane, ale exsituje. A konkretne property, ktere trapi daleko vetsi mnozstvi vyvojaru, porad nenaslo uspokojive resen (pokud teda vim). Podobne je tomu s generikama, ze se k nim nedostanes za behu, to mi prijde taky jako daleko vetsi problem nez jmena parametru.

Nezdá se mi to nijak proti srsti. V případě knihoven co jsem jmenoval (iBatis, Grails) by byly zajímavé právě jen ty argumenty té konkrétní „klientské“ třídy – tedy té nejníž v chainu dědičnosti. Co se týká JDK Proxy nebo Cglibu, taky by neměl být problém.

Interface X Class – Ktere jmeno parametru bude mit prednost?
Predek X Potomek – ktery metodu prekryva, nebo implementuje. – Ktere jmeno bude mit prednost
2x Interface (stejna metoda, jina jmena promenych) implementovano jednou tridu – Ktere jmeno bude mit prednost?

A to vsechno jak dopadne kdyz pouzijeme JDK proxy? A kdyz pouzijeme CGLIB proxy? A budou dalsi nekompatibility pri zamene techto proxy?

Bude nutne aby jmena v implementaci rozhrani byly stejne jaako ve tridach? To ale bude strasne z hlediska zpetne kompatibility. A taky se dostanete do problemu pri immplementaci dvou rozhrani s ruznymi jmeny promenych, ale stejnym jmenem metody.

Nemyslim, ze je tady pekne reseni.

Podle mého názoru stačí pouze jasně říct, v čem je tato technika nebezpečná a že i názvy argumentů jsou součástí rozhraní. Argumentování tím, že jsem se mohl v názvu argumentu uklepnout a chtěl bych to mít možnost bez rizika v dalších verzích opravit je zcestný – stejnou chybu jsem přeci mohl udělat i při psaní anotace nebo názvu metody a v takovém případě mám problém už za současné situace.

Další věc – schválně se zkuste zamyslet nad tím, jestli v názvech argumentů chybujete častěji než v názvech metod – já tedy ne. Co se týká zmíněných použití (iBatis, Grails atd.) – zde je na první pohled jasné a jasně zdokumentované, že názvy argumentů hrají roli, protože se mapují na nějaká externí data (názvy sloupců v db, názvy paramterů v URL atd.). Řekněte mi, kdo by se mohl v daném případě cítit zmatený? Tady jsou argumenty jasně součástí API, což lze jednoduše prověřit testy – ty také zajistí i rychlé zjištění chyb v případě změny API.

Osobně v tom vidím jen riziko v případě, že se to někdo bude snažit zneužívat, jenže v takovém případě už máme řadu jiných podobných nástrojů, které se také dají zneužívat a také nám nevadí (například setAccessible(boolean) že?).

Osobně v tom faktický problém nevidím, a nutnost současný stav obcházet nějakým šíleným oprogramováváním se mi příčí.