Javapolis2007: hlasováních o změnách v jazyce Java

Na javapolis.com byly zveřejněny návrhy komunity pro novou generaci jazyka Java. Rovněž můžete navštívit výsledky hlasování, které jsou tematicky rozdělené na uzávěry (closures), různé změny v jazyce, používané aplikační servery a (nejen javovské) webové frameworky

6.2.2008 09:13 | Michal Vyskočil | Zajímavý článek

Komentáře

[Filip Jirsák]

To je výborné – přes 80 % hlasujících ještě nezaznamenalo existenci enumů, takže požadují switch na String, ale hlavně že požadují closures, se kterými nebudou umět pracovat už vůbec…

[Miloslav Ponkrác]

Proč by nebyl užitečný switch na string? Třeba pro konverzi řetězce ze vstupu na enum? To je jako módní mezi javisty, že zesměšňují každého, kdo požaduje užitečné featury?

[Filip Jirsák]

Proč by nebyl užitečný switch na string? Třeba pro konverzi řetězce ze vstupu na enum?

Myslíte jako vždy ručně znovu implementovat metodu Enum.valueOf(String)? K čemu by to bylo dobré?

To je jako módní mezi javisty, že zesměšňují každého, kdo požaduje užitečné featury?

Nevidím nic užitečného na „featuře“, která s větším množstvím kódu umožňuje něco, co umožňuje už jiná stávající vlastnost (enumy), které jsou navíc kontrolovatelné už v době kompilace.

[Miloslav Ponkrác]

Podle matematické teorie jde naprosto jakýkoli algoritmus napsat pomocí podmíněného příkazu, přiřazení a volání funkce. Cokoli navíc je zbytečné - pokud Váš názor je konzistentní, tak Java v současné době je beznadějně přeplácaná, takže vypiště prosím petici na tvrdé seškrtání Javy.

Umožnění switch na string umožňuje více, než ten váš enum. To, že nemáte dostatek fantazie beru. Sice nepřehledně se to dá emulovat - vytvořit třeba naprosto zbytečný enum s hodnotami všech stringů co potřebuji ve switchi, zkonvertovat string na enum, a pak šup s enum hodnotami do switche, ale považuji to za zbytečnou buzeraci - a přehlednost výsledného kódu bude podstatně nižší, než když v tom switchi budou stringy rovnou.

[Filip Jirsák]

Umožnění switch na string umožňuje více, než ten váš enum. To, že nemáte dostatek fantazie beru. Sice nepřehledně se to dá emulovat - vytvořit třeba naprosto zbytečný enum s hodnotami všech stringů co potřebuji ve switchi, zkonvertovat string na enum, a pak šup s enum hodnotami do switche, ale považuji to za zbytečnou buzeraci - a přehlednost výsledného kódu bude podstatně nižší, než když v tom switchi budou stringy rovnou.

Ty Stringy stejně musím někde vyjmenovat, ať ve switchi, nebo v enumu. Jenom ten enum dává programátorovi i překladači jasně najevo, že je to nějaká omezená množina řetězců, a kompilátor to pak také může kontrolovat (např. kontrolovat, že jste ve switchi ošetřil všechny možné hodnoty). Takže jediný případ, kdy by použití switche místo enumu mělo smysl, je potenciálně nekonečný počet možných vstupních řetězců. Jenomže nekonečný switch taky nejde udělat. Navíc pokud ten program bude mít alespoň nějakou kulturu, nebudete mít řetězce přímo v kódu, ale budete je mít jako konstanty – takže kód bude vypadat skoro stejně, jako s použitím enumu, ale nebude tam ta kontrola v době překladu. Jinak v kódu je rozdíl mezi enumem a switchem volání jediné metody, což těžko výrazně sníží přehlednost kódu.

[Miloslav Ponkrác]

A kompilátor ve switchi nemůže zkontrolovat to všechno co tu píšete? Kompilátor nemůže zkontrolovat, že jste ve switchi ošetřil všechny možné hodnoty? To jsou mi novinky. Znovu opakuji, že to, že Vaše fantazie je omezená na to, kde se dá použít string ve switch - není problém stringu ve switchi.

Pokud kód bude mít kulturu, tak bude psán tak, aby byl co nejpřehlednější, nejudržovatelnější a nejčitelnější - což nutně neevokuje mít všechny literály jako konstanty - to tu zase tvrdíte něco co není pravda. To už taky můžete tvrdit, že vhodné programování je stylem:

... final int MUL_CONST = 2; ...

public int mul_by_two(int operand) { return operand * MUL_CONST; }

Jestli programujete výše uvedeným stylem, to jest všechny literály tlačíte na sílu jako konstanty, tak potěš pámbů. A je úplně jedno, jestli jde o čísla, stringy, nebo jiné typy - někdy je vhodné je definovat jako konstanty, a někdy je vhodnější je zapsat přímo do kódu.

Rozdíl mezi enumem a switchem není volání jedné metody.

[Filip Jirsák]

A kompilátor ve switchi nemůže zkontrolovat to všechno co tu píšete? Kompilátor nemůže zkontrolovat, že jste ve switchi ošetřil všechny možné hodnoty? To jsou mi novinky. Znovu opakuji, že to, že Vaše fantazie je omezená na to, kde se dá použít string ve switch - není problém stringu ve switchi.

Pokud kompilátoru předem nedám seznam všech přípustných hodnot, nemůže zkontrolovat, že jsem pro každou přípustnou hodnotu napsal odpovídající větev case. Pokud by switch pro Stringy přinášel i tu možnost určit všechny přípustné hodnoty, dostanete enum. Tak proč ho vymýšlet podruhé?

Pokud kód bude mít kulturu, tak bude psán tak, aby byl co nejpřehlednější, nejudržovatelnější a nejčitelnější - což nutně neevokuje mít všechny literály jako konstanty - to tu zase tvrdíte něco co není pravda.

Hodnoty ve switchi nejsou jen tak nějaké hodnoty spadlé z nebe, ale je to několik hodnot z omezené množiny. Místo takových hodnot se typicky používají konstanty, protože je většinou používáte na více místech. Jenomže pro omezenou množinu hodnot už má Java vlastní datový typ – enum. A jsme zase zpátky na začátku.

Rozdíl mezi enumem a switchem není volání jedné metody.

Najděte víc jak jeden rozdíl:

private static final String ONE = "ONE";
private static final String TWO = "TWO";
private static final String THREE = "THREE";

switch (str) {
  case ONE: doOne(); break;
  case TWO: doTwo(); break;
  case THREE: doThree(); break;
}

private enum Numbers { ONE, TWO, THREE};
switch (Numbers.valueOf(str)) {
  case ONE: doOne(); break;
  case TWO: doTwo(); break;
  case THREE: doThree(); break;
}

Já v tom z hlediska kódu vidím jediný rozdíl, volání metody Numbers.valueOf(String). Z hlediska významu tam vidím minimálně další dvě věci, obě ku prospechu enumů:

private enum Numbers { ONE, TWO, THREE};
switch (Numbers.valueOf(str)) {
  case ONE: doOne(); break;
  case TWO: doTwo(); break;
}

Kompilátor může dát varování, že je switch neúplný, a:

private enum Numbers { ONE, TWO, THREE};
switch (Numbers.valueOf(str)) {
  case ONE: doOne(); break;
  case TWO: doTwo(); break;
  case THREE: doThree(); break;
  case WINTER: doWinter(); break;
}

Tohle vám kompilátor s enumem ani nepřeloží. Se Stringem to v obou případech projde, a divit se budete až za běhu programu.

Znovu opakuji, že to, že Vaše fantazie je omezená na to, kde se dá použít string ve switch - není problém stringu ve switchi.

Mohl byste napsat nějaký konkrétní příklad? Podle mne 99,99 % užití Stringu ve switchi je případ, kdy mám předem známou množinu řetězců, které očekávám někde na vstupu, a potřebuju zjistit, která konkrétní hodnota na tom vstupu je. Přesně k tomuhle ale má Java enum, a není důvod zavádět další konstrukci (Java není Perl). Ta zbývající desetina promile jsou případy, kdy by se autor kódu měl přeci jen zamyslet, zda to nemá být enum… Napadá mne vlastně jediný případ, kdy nejde enum použít přímočaře, a to je nemožnost dědění enumů. A i v takovém případě je implementace s využitím enumu lepší, než switch se Stringy, které se vám náhle z ničeho nic zjeví v kódu.

[zoul]

Obdivuhodná trpělivost.

[qk_]

Naprosto souhlasim. Ono obecne spousta lidi nepouziva enumy v jave, i kdyz to je hodne uzitecna vec.
Pomaha to i v udrzovatelnosti kodu po rozsireni, kdy musite pridat nejakou funkci a tak pridate moznost do enumu a prekladac rekne, pokud je v nejakym switchy tato moznost opomenuta a tak se predejde dost chybam, ktere by se jinak spatne hledali.
Jinak vas obdivuju tak dlouho nekoho presvedcovat o necem co je pomerne jasne a co kazdy rozumny programator vi. Jedine kdy by bylo switchovani podle stringu uzitecne je pres regexpy...ale to si myslim ze je zhruba tak slozite jako napsat metodu, ktera ten regexp prevede na hodnotu v enumu a navic zas tak casto se regexpy nepouzivaji.

[KsR]

celá tahle diskuze je ujetá -ve skutečnosti tady jeden druhému jen říká, kdo je větší "blbec". A přitom neumíte ani psát česky:) "Češtin můj kobil", co?

[Daniel Kvasnička ml.]

http://www.xefer.com/2006/12/switchonstring

[qk_]

Tento zapisek pouze rika, ze by bylo dobry mit v enumu nejakou hodnotu, kdyz dany string neni v enumu misto hazeni vyjimky. Coz mi ale nepripada tak tezky udelat. pokud clovek chce tak si to celkem rychle a elegantne obali treba jako v tom clanku pomoci dalsi hodnoty enumu jako NONDEF a tridy, kde si odchyti tu vyjimku a vrati tu NONDEF hodnotu enumu.
Ale mne pripada tedy reseni s vyjimkami podstatne lepsi. Napriklad v SAXu, kdyz jinou hodnotu nez definovanou (a nemam kontrolu pres xsd), tak zavolat nejakou masineriji na zpracovani a az na vrsku odchytavam ruzne exceptiony, ktere vyvola ta masinerie a znamenaji vetsinou nejakej fatal (napriklad spatna cesta k souboru, spatne hodnoty atd) a tak preskocim cely zpracovavani danyho elementu.

[Daniel Kvasnička ml.]

Ja jsem to sem dal jen proto, ze hned ze zacatku je ukazano jak se da enumem nahradit switch na stringy... Jak to ukazuje Filip Jirsak vyse. Switch na stringy je v podstate zbytecny.