v .NETu vám IList<string> s = ...; IList<object> o = (IList<object>) s; spadne za běhu na System.InvalidCastException: Unable to cast object of type 'System.Collections.Generic.List`1[System.String]' to type 'System.Collections.Generic.IList`1[System.Object]'. Lze ale napsat IEnumerable<object> o = s; protože je IEnumerable definován jako koo. viz IEnumerable<out T> http://msdn.microsoft.com/en-us/library/9eekhta0.aspx potom můžeme pole procházet. Jinak souhlasím že v .NETu jsou generické typy promakanejší:-)
Petr Dne 20. září 2011 23:41 "Zdeněk Troníček" <[email protected]> napsal(a): > Podle mého názoru jsou generické typy v .NET trochu lepší. Hlavní argument > je ten, že odmazaní typového parametru vede k tomu, že jej nelze použít > např. za new nebo instanceof. A to většina programátorů neočekává. Proto > se mi zdají generické typy v .NET více intuitivní a tudíž lepší. > > Z.T. > -- > Zdenek Tronicek > FIT CTU in Prague > > > Ondra Medek napsal(a): > > Nebyl bych si tak jisty, jestli to reseni v .NET je lepsi nez v Jave. > > V .NET museli pridat dalsi vlastnost jazyka "in" a "out", cimz se > > jazyk zase komplikuje. V Jave je bezne, kdyz uz ty generika > > programatora s**ou udelat jiz uvedene > > > > List<T> list = (List)listParam; //překladačem projde i za runtime a > > > > spolu se SupressWarning a jede se vesele dal. Takove reseni jsem beze > > videl treba v Hibernate nebo jinych proflaklych knihovnach, i kdyz > > nekdy sla dana situace vyresit spravnou aplikaci Java generik > > (extends, super, ?). > > > > Ano zaryti puriste jiste vznesou namitky, ale pokud je funcknost > > uzavrena v nejake tride/metode/modulu a otestovana, tak to IMHO > > nevadi. > > > > 2011/9/20 Petr Balat <[email protected]>: > >> - Dobře tedy pro kompilátor je to jiná třída ale výsledek pro jvm je to > >> ta > >> samá. na tom se snad shodneme at tu neslovičkaříme > >> :-) > >> - jinak jsem psal ze generiky pro překladač nejsou koo. ani koontra. tak > >> jak > >> jste vypsal odstravec z wiki viz "Unlike arrays, generic > >> classes are neither > >> covariant nor contravariant". > >> Nicméně myslím si že je důležitější vědět jak se generiky mají v plném > >> kontextu, takže i vlastnosti jvm, proto ten komentář. > >> Aby se začátečník nespletl např. při kontrole instanceof apod. kde ten > >> rozdíl mezi runtime a kompilaci je potřeba znát. > >> Pokud programátor potřebuje pracovat s reflexí tak už tato znalost je > >> nutná. > >> -ano do .net museli přidat koo. a kontra. v gener. protože to nešlo > >> obejít > >> tak jako v jave (když pomineme warning za předpokladu že programátor > >> musí > >> znát i výsledek kompilace). > >> V .NETu je IList<string> a IList<object> jinej typ jak pro kompilátor > >> tak i > >> pro virtuální mašinu. > >> List<Predek> map = (List)listPotomek; //překladačem projde i za runtime > >> a > >> nejspíš bude typová kontrola pro další část kódu užitečná. > >> //v .net by to za runtime spadlo > >> Petr > >> > >> > >> Dne 20. září 2011 15:15 "Zdeněk Troníček" <[email protected]> > >> napsal(a): > >>> > >>> Ladislav Thon napsal(a): > >>> >> - V Javě je Iterable<String> potomkem Iterable<Object> protože je to > >>> > v reálu ten samej objekt - pouze překladač nás může chránit tak jako > >>> > máte > >>> > ve > >>> > 2 příkladě.. (to samé pro List) > >>> > > >>> > IMHO nejlepší je dívat se na parametrizované třídy jako na funkce, > >>> které > >>> > vytváří "normální" třídy, a vykašlat se na implementační detaily (i > >>> když > >>> > ty > >>> > detaily v Javě jsou někdy bohužel pekelně důležité). > >>> > > >>> > A i když sestoupíte na tu implementační úroveň, stejně není > >>> podstatné, > >>> > jestli je Iterable<String> potomkem Iterable<Object> (což technicky > >>> je, > >>> > pokud definujeme relaci dědičnosti jako reflexivní), ale to, jestli > >>> > Iterable<String> je nebo není _podtypem_ Iterable<Object>. A to > >>> rozhodně > >>> > není. > >>> > >>> Jenže tahle diskuze je o překladu a warningu překladače. Jinak Tvoje > >>> terminologie mě překvapuje, protože pro mě jsou potomek a podtyp > >>> synonyma. > >>> > >>> Z.T. > >>> -- > >>> Zdenek Tronicek > >>> FIT CTU in Prague > >>> > >> > >> > > > > > > > > -- > > Ondra Medek > > > > > >
