K čemu je v Javě prázdný String konstruktor?

[kuka]

U Array to nevadí?

Ne nevadi. BTW jak Array souvisi s generiky a jejich typovou bezpecnosti?

[Reklama]

[Jakub Galgonek]

U Array to nevadí?

Tohle se u polí kontroluje, viz ArrayStoreException.

[Ladislav Thon]

Tedy bych si deklaroval List<Y> a predal ho metode, ktera pracuje s List<X>. Ta by do nej pridala instanci tridy Z (ktera je rovnez potomkem X). Potom bych postupne zpracoval prvky sveho List<Y> a volal na nich metody tridy Y. Co by se stalo, az bych narazil na instaci tridy Z? Kde by byla slibovana typova kontrola? Pro nazornost si dosadme treba X=Number, Y=BigDecimal, Z=Short.

U Array to nevadí?

Čistě z pohledu typového systému jsou kovariantní pole špatně a invariantní generiky správně. Ovšem use-site variance je peklo na druhou...

[Mirek Prýmek]

Ne nevadi. BTW jak Array souvisi s generiky a jejich typovou bezpecnosti?

No tak, že to, co u generik vůbec nejde, to u Array jde, ale vyvolá to runtime výjimku.

[Mirek Prýmek]

Čistě z pohledu typového systému jsou kovariantní pole špatně a invariantní generiky správně. Ovšem use-site variance je peklo na druhou...

Můžeš trochu rozvést důvody? (pokud možno tak, abych to jako ne-fulltime programátor, ne-javista pochopil

[Reklama]

[Javista]

Čistě z pohledu typového systému jsou kovariantní pole špatně a invariantní generiky správně. Ovšem use-site variance je peklo na druhou...

Můžeš trochu rozvést důvody? (pokud možno tak, abych to jako ne-fulltime programátor, ne-javista pochopil

U generik je to správně proto že kontroly provádí přímo kompilátor. U polí je to špatně protože kompilátor nekontroluje a může to tedy vést k pádům programů za běhu, což je přesně to co by silně typový jazyk neměl dovolovat. No a to že je to jednou tak a podruhé tak je prostě to peklo na druhou...

[kuka]

No tak, že to, co u generik vůbec nejde, to u Array jde, ale vyvolá to runtime výjimku.

A prave proto, ze by to vyvolalo behovou vyjimku, to u generik nejde, coz jsem se snazil vysvetlit. Tam by to vadilo, protoze generika zarucuji, ze k behove vyjimce nedojde, protoze se nesoulad typu objevi uz pri prekladu - to je ostatne hlavni prinos generik. Pole to nezarucuji a proto to u nich nevadi, kazdy proste vi/mel by vedet, ze k takove situaci muze dojit. Princip typove kontroly poli a generik je uplne jiny, coz je sice sveho druhu "souvislost", podle mne ale vzhledem k tematu generik irelevantni.

[Mirek Prýmek]

U generik je to správně proto že kontroly provádí přímo kompilátor. U polí je to špatně protože kompilátor nekontroluje a může to tedy vést k pádům programů za běhu, což je přesně to co by silně typový jazyk neměl dovolovat. No a to že je to jednou tak a podruhé tak je prostě to peklo na druhou...

Ok, hledal jsem za tím něco složitějšího. Jestli je to správně, to nevím. Je to prostě tak Má to taky své nevýhody a v jiných jazycích se to afaik řeší jinak.

A prave proto, ze by to vyvolalo behovou vyjimku, to u generik nejde, coz jsem se snazil vysvetlit. Tam by to vadilo, protoze generika zarucuji, ze k behove vyjimce nedojde, protoze se nesoulad typu objevi uz pri prekladu - to je ostatne hlavni prinos generik. Pole to nezarucuji a proto to u nich nevadi, kazdy proste vi/mel by vedet, ze k takove situaci muze dojit. Princip typove kontroly poli a generik je uplne jiny, coz je sice sveho druhu "souvislost", podle mne ale vzhledem k tematu generik irelevantni.

No takže u polí to vadí taky, ale tam to "každý ví"

[Natix]

Pokud jde o generické wildcards, tak tam se člověk hodně rychle dostane do situací, kdy se mu dělají uzly na mozku. 

Jen tak pro zajímavost:
- do List<? extends Number> nemůžu nic vložit, maximálně null
- z List<? super Number> nemůžu odebírat, respektive mám zaručeno pouze to, že tyto objekty budou implementovat lava.lang.Object

Naštěstí existuje docela použitelná mnemotechnická pomůcka od Joshe Blocha: PECS - Producer Extends, Consumer Super
Nicméně už jenom přijít na to, co je ten producent a konzument, je občas problém. Pak to vede na úchvatné signatury metod typu:

Kód: [Vybrat]

public static <T extends Comparable<? super T>> void sort(List<T> list)

[kuka]

A prave proto, ze by to vyvolalo behovou vyjimku, to u generik nejde, coz jsem se snazil vysvetlit. Tam by to vadilo, protoze generika zarucuji, ze k behove vyjimce nedojde, protoze se nesoulad typu objevi uz pri prekladu - to je ostatne hlavni prinos generik. Pole to nezarucuji a proto to u nich nevadi, kazdy proste vi/mel by vedet, ze k takove situaci muze dojit. Princip typove kontroly poli a generik je uplne jiny, coz je sice sveho druhu "souvislost", podle mne ale vzhledem k tematu generik irelevantni.

No takže u polí to vadí taky, ale tam to "každý ví"

Pouzij prosim hlavu a zamysli se nad tim, co znamena, kdyz neco zarucuje specifikace - to proste fungovat MUSI. U poli to mozna subjektivne vadi tobe, ale to je trochu jiny smysl slova "vadit". Nekompatibilita poli a generik je problem, ktery realne nastava minimalne. V 99% uloh neni zadny duvod pouzivat pole misto kolekci a nedoporucuje se to (napr. proto, ze pole jsou z principu vzdy modifikovatelna). Pole maji misto tam, kde je potreba vysoky vykon, predevsim ve vztahu k primitivnim typum.

[Mirek Prýmek]

Pak to vede na úchvatné signatury metod typu:

Kód: [Vybrat]

public static <T extends Comparable<? super T>> void sort(List<T> list)

No dyť jsem říkal, že z toho na mě dýchá C++

[Mirek Prýmek]

@kuka: asi si nerozumíme. Chtěl jsem říct, že ve mně budí podezření jazyky, kde A funguje nějak a B, které je A velmi podobné, funguje úplně opačně - ale zároveň komunita tvrdí, že to, jak B funguje, je bomba.

[podlesh]

V 99% uloh neni zadny duvod pouzivat pole misto kolekci a nedoporucuje se to (napr. proto, ze pole jsou z principu vzdy modifikovatelna). Pole maji misto tam, kde je potreba vysoky vykon, predevsim ve vztahu k primitivnim typum.

Pole se bohužel používají zcela běžně jako varargy...

Dále jsou běžné v různých API včetně těch základních (java.*, javax.*) a kolekce jsou koneckonců implementované nad nimi (a celé praktické používání generik je pak zajištěno tím že jsou na implementacích vypnuté pomocí @SuppressWarning, což je dost drsný hack).

Bohužel toho všeho se nedá jen tak jednoduše vyřešit bez problémů se zpětnou kompatabilitou nebo novou "paralelní" verzí jazyka. A v tom případě je lepší prostě použít zbrusu nový jazyk. Například Groovy, Scala, Clojure.

[podlesh]

Pak to vede na úchvatné signatury metod typu:

Kód: [Vybrat]

public static <T extends Comparable<? super T>> void sort(List<T> list)

No dyť jsem říkal, že z toho na mě dýchá C++

To je matematika (viz http://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)), takže to tak nějak dopadnout musí (dokonce ani přesun do jiného vesmíru nepomůže).

[kuka]

@kuka: asi si nerozumíme. Chtěl jsem říct, že ve mně budí podezření jazyky, kde A funguje nějak a B, které je A velmi podobné, funguje úplně opačně - ale zároveň komunita tvrdí, že to, jak B funguje, je bomba.

Aha, podezreni neni to, o cem bych se chtel bavit, natoz o komunite. Ja jsem chtel pouze vysvetlit, proc neni spravna tvoje uvaha, ze "pro Y potomka X bych List<Y> mel mit moznost pouzit kdekoliv, kde List<X>, aniz bych to nejak specialne daval najevo". Bud se to povedlo, nebo nepovedlo, ale vic k tomu asi neni co rict.