javapolis a zmeny jazyka Java

6.2.2008 23:58 | Přečteno: 1487× | software | poslední úprava: 7.2.2008 00:16

Pri procitani vysledku z javapolis, jsem zacal premyslet o tom, zda dane featury do javy skutecne chci, ci nikoli.

Zmeny jazyka Java

closures - dobry bordel, ktery z cisteho a prehledneho jazyka udela tezkopadnou mrchu :(

Property declaration - nesmysl, ktery se ma jen okopirovat od C#. Stejne je to s Property access, kde by se casto mohlo stat, ze se zameni s primym pristupem k atributu tridy a tim se porusi zapouzdrenost.

Improve generics - V urcitych oblastech sve misto ma, navic generika se v posledni dobe dostava "dodelava" snad do kazdeho API, co znam.

Access List and Map using [] - opet dalsi blbost. Zavadi do jazyka "novou" syntaxi, ktera neni zrovna v souladu s OOP. Maximalne bych videl neco takoveho pro pouziti pri vytvareni instance, nikoli behem zivota.

String switch - i kdyz je vyse popsano, ze enum dokaze dany zpusob nahradit, ja osobne bych byl pro. Umozni to mene psani. Zejmena ve chvili, kdy zpracovavam "neznama" data a dost casto dochazi ke zmenam.

Typedef - jako pokus o zert to neni spatne. Samozrejme v zadnem pripade!

Multi-catch - zde jsem pro. Zejmena ve chvilich, kdy vyjimky nezahazuji a resim je na vyssi urovni, kde se mi muze sejit pekna radka exceptions.

Null-handling - ee, dalsi cukratko, ktere jen vnasi nesmyslnou syntaxi do cisteho jazyka.

Kdyz to tak sectu, tak bych byl asi radsi, kdyby "nova" java neobsahovala to, co je navrhovano. Nejde o to, ze bych byl proti inovacim, naopak, ale ty museji byt v souladu s celym konceptem. V dnesni dobe je velice modni pouzivat dynamicky typovane jazyky. Chapu, ze v urcitych oblastech je vyhodnejsi takovy jazyk, ale java je pravym opakem a jako takova ma svoje místo mezi velkymi systemy, které se museji slozite udrzovat.

Aplikacni servery

Zde k moc velkym prekvapenim nedoslo. Mozna jen glassfish, který si stále ziskava vice a vice lidi. Na to, ze je o dost mladsim AS (tedy jako open-source), je to uctyhodne cislo. Vidim pozitivne to, ze aplikacnich serveru je vice. Konkurencni prostredi muze dopomoci zvysovani kvality danych AS.

Webove frameworky

Pri tak ohromnem mnozstvi webovych frameworku se tato „anketa-statistika“ stava nepouzitelnou. Také proto, ze nektere frameworky jsou doplnujici ostatnich, (viz. JSF-Seam).

Jako člověka, který se javou zivi, bych radeji uvital vetsi tlak na J2EE specifikaci, která je stále dost tezkopadna a dane standardy SUNu jsou často nedostacujici (viz. JPA vs. Hibernate, EJB3 vs. Spring).

       

Anketa

Komentáře

[Ladicek]

closures - dobry bordel, ktery z cisteho a prehledneho jazyka udela tezkopadnou mrchu :(

přehledného?

S tím ostatním povětšinou souhlasím. A bohužel marně doufám v nativní podporu AOP na úrovni virtuálního stroje, to by bylo vylepšení, na které se konkurence nezmůže!

[Kyosuke]

Ale zmůže, a to už aspoň dvě dekády. Tedy pokud řeč není jen o konkurenčních implementacích Javy, včetně .NETu, který tam po soudném zhodnocení fíčur a pohledu s odstupem počítám taky.

[Ladicek]

Lisp je úplně jiná liga, to je snad jasné Některé navrhované změny jsou jasnou snahou přiblížit se sýšárpu. Ale takové nativní AOP (třeba jak ho vymysleli a experimentálně implementovali u Bey) by nechalo celý dodNet někde daleko tam (Dost možná, že jenom v mých očích, ale co už )

[thingie]

Odmítat v Javě syntaktický cukřík na datové struktury jako mapa a tak je masochismus na druhou nejmíň, tyjo. Closuers se do Javy asi syntakticky dvakrát nehodí anžto je to špatnej jazyk, ale jinak teda nevim jak si chce bez nich jazyk říkat vysokoúrovňový.

[thingie]

A co má kdo proti tomu typedefu, to mi taky není jasné. Je to maličká blbost, kterou není důvod nemít.

[miro]

Aby clovek potom zistoval, co to v skutocnosti je LPCSTR, word, PULONG, PDWORD a podobne?

Nic ma neodradovalo od microsoftich ceckovskych kniznic viac ako toto.

[thingie]

Obor platnosti takové definice by měl podle všeho být jeden soubor, co je na tom za zjišťování. Navíc takovéhle věci asi není důvod dělat. Hezké by to mohlo být, když se hryže víc jmen z různých balíků. (A kam se poděly tak často připomínané velkoIDE, najednou?)

[Bluebear]

V jednom projektu, na kterém jsem škodil, jsme měli typedefy uchar (unsigned char) a schar (signed char). Snažil jsem se prosadit, abychom podporovali Unicode a zavedli typ "big char" a "small char", čímž by vznikly kombinace buchar a suchar.

[Deleted [8409]]

Tak toto mě pobalivo, dobrý žertík :)

[Bluebear]

Možná, že potřeba typedefu vyplynula ze zavedení generických tříd. V C++ se dost často stane, že při použití templatů (zejména když jsou pěkně vnořené do sebe) je jméno typu delší než 80 znaků. Pak představuje typedef jedinou šanci, jak se neupsat k smrti.

[PMD]

A kterej jazyk je "dobrej" ?

[happy barney]

bez definície dobrej je to fajn flame otázka
imho perl 6 má šancu stať sa tým "najpravítkovatejším"/"najchladnejším" jazykom v dennej ponuke

[thingie]

Nepotřebuju mít nějaké ,dobré` abych mohl mluvit o špatném

[Bluebear]

Nepotřebuju mít nějaké ,dobré` abych mohl mluvit o špatném

To sice nepotřebuješ, ale pak se může stát, že to, co označuješ za špatné, je ve skutečnosti nejlepší dosažitelné řešení.

[podlesh]

Odmítat v Javě syntaktický cukřík na datové struktury jako mapa a tak je masochismus na druhou nejmíň, tyjo. Closuers se do Javy asi syntakticky dvakrát nehodí anžto je to špatnej jazyk, ale jinak teda nevim jak si chce bez nich jazyk říkat vysokoúrovňový.

Java není vysokoúrovňový jazyk. To je velice rozšířená iluze a zdroj mnoha zbytečných flamewarů.

Java jako platforma je možná high-level (protože VM), ale samotný jazyk Java je relativně k této platformě docela low-level (z kódu je jasně vidět, jaký bytecode vznikne překladem).

[Heron]

Po přečtení nadpisu a prvního řádku jsem se lehce zděsil, ale ono to není nakonec tak hrozné. Nakonec totiž nejvíce záleží na kvalitě programátora. Teď jsem asistoval u jednoho projektu, kde hlavní autor zásadně nepoužíval enum (nebo něco na této úrovni) a všude používal int. Děs. Na rozlišení pohlaví používal boolean. Chápal jsem to tak, že daná osoba má/nemá pohlaví . Ostatní věci také neměl nijak pojmenované (typově) a tak na 90% položek stačil string. Raději nemluvit o OOP. Jestli tohle někdo uvidí, tak si Javu znechutí do konce života.

Ty změny jsou dobré, pokud se budou dobře používat. Třeba ten přístup k Množinám. Ten používat nebudu. Pole jako takové používám minimálně. Je to příliš nízkoúrovnový prvek a ve svých projektech jej nepotřebuji. String switch se může hodit. Generiky jsou perfektní nástroj k zajištění silnější typové kontroly, takže taky paráda. typedef je špatný vtip, v tom souhlas. Není mi jasné k čemu by to mělo sloužit.

[Michal Vyskočil]

No viděl jsem kód od "skutečného" programátora - na všechno stačí pole, if (no dobrá, občas i cyklus, pokud nechceme používat goto) a String. No a co jsem já jako pojídač koláčů napsal do kraťoučké* třídy, která vlastně jenom obalovala staticky inicializovanou HashMapu, to on zvládl rozepsat do procedurálního kódu ve stylu

if (foo.equal("cond1")) {
   bar = "X";
   baz = "Y";
}
else if (foo.equal("cond2")) {
   bar = "Z";
   baz = "X";
}
...

* kraťoučké ve smyslu Javy, ovšem pokud by měla zabudovaný typ seznam, nebo ntice, bylo by to daleko kratší

Čímž ho nechci nikterak pomlouvat, množství kódu, které dokázal napsat, bylo skutečně velice působivé a narozdíl od jiných to neměl potřebu dohánět ASCII artem v komentářích (ty naopak chyběly úplně).

[Heron]

na všechno stačí pole, if (no dobrá, občas i cyklus, pokud nechceme používat goto)

Ano stačí. Dá se programovat i ve strojovém kódu. Otázkou je, kdo se v tom pak vyzná. Osobně se snažím především o maximální přehlednost. Co mi o sobě řekne typ string? Že je tam řetezec. To je tak asi všechno . Když chci ukládat jména, vytvořím si třídu Name (případně i potomky pro spec případy) a hned je mi jasné, s čím mám tu čest. I kdyby součástí té třídy měl být pouze jeden argument typu string.

[Daniel Kvasnička ml.]

na všechno stačí pole, if (no dobrá, občas i cyklus, pokud nechceme používat goto)

Ano stačí. Dá se programovat i ve strojovém kódu. Otázkou je, kdo se v tom pak vyzná. Osobně se snažím především o maximální přehlednost. Co mi o sobě řekne typ string? Že je tam řetezec. To je tak asi všechno . Když chci ukládat jména, vytvořím si třídu Name (případně i potomky pro spec případy) a hned je mi jasné, s čím mám tu čest. I kdyby součástí té třídy měl být pouze jeden argument typu string.

Takze kdyz budes delat DB aplikaci, vytvoris si tridu pro kazdy nazev sloupce, ktery v DB je? Chapu to, kdyz jde treba o jmeno a prijmeni. Tam uz to ma smysl. Ale jedina property, kdyz neni v dohlednu pripad, kdy bych potreboval dalsi?...

[Heron]

kdyz neni v dohlednu pripad, kdy bych potreboval dalsi?.

Jenže až ji budeš potřebovat, nemusíš měnit zbytek kódu. Ten už totiž pracuje s objekty dané třídy (na místo základních typů).

[Daniel Kvasnička ml.]

kdyz neni v dohlednu pripad, kdy bych potreboval dalsi?.

Jenže až ji budeš potřebovat, nemusíš měnit zbytek kódu. Ten už totiž pracuje s objekty dané třídy (na místo základních typů).

Trosku agility by neskodilo Budes vymyslet ficurky, vychytavky, rozsireni a vsechno mozny a pak zjistis, ze 90% funkcionality klienta vubec nezajima i kdyz tebe naprosto fascinuje, jak genialne jsi to naprogramoval... Refaktoring uz je dneska celkem bezna vec a IDE ho zvladaji dobre. Navic vlastni trida a primitivni typ je imho jisty pametovy rozdil a pri velkem zatzeni aplikace to muze hrat roli.

[Heron]

Budes vymyslet ficurky, vychytavky, rozsireni a vsechno mozny

Nebudu. Na to já nejsem. Já mluvil o kvalitě kódu, nikoliv o možnostech aplikace. A protože jsem líný programátor, tak to píšu pořádně hned od začátku, ať pak nemám práci s implementováním pitomostí, co si vymyslí zadavatel (ten kód už bude na ty pitomosti připravený). Mnohokrát se mi to již vyplatilo.

[Michal Vyskočil]

Když chci ukládat jména, vytvořím si třídu Name

A o Adě jsi už slyšel? Možná by tvému přístupu programování odpovídala přeci jenom o nšco víc, než Java

[Heron]

Slyšel. Není čas na experimenty, produkce je důležitější.

[happy barney]

typedef v zmysle dočasného vytvorenia aliasu k inému typu je dobrá možnosť. Napríklad konverzné funkcie (aha, pardon, java, konverzné metódy konverzných objektov ) medzi dvoma knižnicami používajúcimi kilometrové názvy tried ako na potvoru líšiacimi sa len na začiatku. Podobné prípady sa nájdu ku všetkému.

a nezabudnite, strašiaci menom TIMTOWDI, overload operátorov a multiple inheritance sa pri približovaní javy k potrebám praxe prídu aj k vám

[ajikdpoe]

ten switch bol imho mysleny nejak takto:

public enum Suit { CLUBS, DIAMONDS, HEARTS, SPADES };

public stringToSuit(String nieco) {
  switch (nieco) {
    case "CLUBS": return CLUBS;
    case "DIAMONDS": return DIAMONDS;
    case "HEARTS": return HEARTS;
    case "SPADES": return SPADES;
  }
}

[finc]

No nevim, proc delat takovy obal. Stale mi prijde rozumnejsi umoznit pouzit string naprimo:

switch(hodnota) { case "prvni": runFirst(); case "neco": runNeco(); }

Pouziti enum neni nijak pracne, ale vadi mi 2 veci:

• nutnost definovat enum
• v pripade neexistence je treba obalovat to vlastni metodou a zachytit vyjimku.

Naopak vitanou moznosti je fakt, ze mam presny vycet moznosnosti, ktere mohou nastat. Samozrejme je to cistci, nikoli vsak jednodussi a prehlednejsi.

Pokud ma nova java prinest neco noveho, melo by to byt snadnejsi cteni, jednodussi zapis (na urovni konceptu javy a na urovni konceptu OOP).

Nevim jak ostatni lide, ale ja mam pocit, ze cim vice bude moznosti, tim mene bude kod prehledny. Dnes muzu kod cist jako knihu, muze ovsem nastat chvile, kdy budu u 10 radku kodu premyslet, co tim autor ci ja sam zamyslim. :(

[Filip Jirsák]

Naopak vitanou moznosti je fakt, ze mam presny vycet moznosnosti, ktere mohou nastat. Samozrejme je to cistci, nikoli vsak jednodussi a prehlednejsi.

Pak mi ale není jasné, proč kvůli tomu zavádět novou konstrukci do jazyka. Vždyť nečistě ale jednodušše a přehledně to jde zapsat už teď pomocí else-ifů. A zavádět nové vlatnosti jazyka ad-hoc proto aby se usnadnilo psaní jedné konkrétní nečisté konstrukce, to není moc dobrý nápad… Vždyť jsou zde jiné programovací jazyky, kdde si takovouhle špinavou konstrukci může programátor zavést na svoje triko, a nemusí tím obtěžovat všechny ostatní uživatele toho jazyka. Java je v tomhle jiná, tam si nenadefinujete nové jiné operátory ani nové typy, a je to její vlastnost. Pokud má někdo potřebu tuhle vlastnost obcházet, asi zvolil špatný programovací jazyk.

[happy barney]

Pak mi ale není jasné, proč kvůli tomu zavádět novou konstrukci do jazyka. Vždyť nečistě

možno je v tom sprisahanie výrobcov čistiacich prostriedkov

Pokud má někdo potřebu tuhle vlastnost obcházet, asi zvolil špatný programovací jazyk.

obchádza sa nedokonalosť ... a že píšete zvolil špatne práve v tomto threade ...

[Kyosuke]

Myslím, že po bezhlavém zavedení parametrizovaných typů do dynamicky typovaného objektového runtimu podporujícímu změny stavu objektů ztrácejí argumenty o "ad-hocovitosti" a "špinavých konstrukcích" docela smysl.

[Heron]

Pokud by ta metoda stringToSuit byla součástí toho enum, a pokud by ty stringy ("CLUBS"...) byli definovány u jednotlivých položek, tak souhlas. Tohle není zapouzdřené.

Takhle nějak:

public enum Suit {
  CLUBS("CLUBS"),
  DIAMONDS("DIAMONDS"),
  HEARTS("HEARTS"),
  SPADES("SPADES")
  
  private String text;

  public Suit(String t) {
    text = t;
  }

  public String toString() {
    return text;
  }

  public Suit getSuit(String nieco) {
    switch (nieco) {
      case CLUBS.toString(): return CLUBS;
      case DIAMONDS.toString(): return DIAMONDS;
      case HEARTS.toString(): return HEARTS;
      case SPADES.toString(): return SPADES;
    }
  }
};

[Filip Jirsák]

Eh, co to má být? To je pokus o co nejsložitější implementaci něčeho? Ještě by šlo tam někam zakomponovat reflexi, ta tam vyloženě chybí…

[Heron]

Napiš to jednodušeji. Požadavek: zapouzdřený enum; převod string na ten enum. Mé řešení má pouze jednu výkonnou metodu.

[Filip Jirsák]

Nevím, čemu říkáte „zapoudřený enum“ – pokud tomu, že enum má v sobě nějaký String jiný od názvu enumu, pak se připravujete o to nejdůležitější – kontrolu v době kompilace a možnost refaktoringu bez nějakého hádání, zda ty dva Stringy jsou stejné jenom náhodou nebo záměrně. Ale prosím:

public enum Suit {
  CLUBS("First"),
  DIAMONDS("Second"),
  HEARTS("Third"),
  SPADES("Fourth");
		  
  private String text;

  private Suit(String t) {
    text = t;
  }

  public String toString() {
    return text;
  }

  private static final Map<String, Suit> textMap;
		  
  static {
  	textMap = new HashMap<String, Suit>(Suit.values().length);
  	for (Suit suit : Suit.values()) {
  		textMap.put(suit.text, suit);
  	}
  }
		  
  public static Suit getSuit(String nieco) {
  	return textMap.get(nieco);
  }
}

Má to jedinou nevýhodu – není tam tolik oblíbený switch, takže pokud do enumu přidám další položku, nemusím už rozšiřovat žádný převodní switch.

Pokud si enumy pojmenujete rovnou tím významovým textem, nepotřebujete ani tu mapu a příslušnou metodu máte už rovnou v runtime knihovně:

public enum Suit {
  CLUBS,
  DIAMONDS,
  HEARTS,
  SPADES;
  public static Suit getSuit(String nieco) {
  	//samozřejmě lze volat rovnou, není potřeba převolávací metoda
  	return Suit.valueOf(nieco);
  }
}

Pokud kód, který chcete „switchovat“ souvisí spíše s enumem než se třídou, ve které by byl switch, můžete dokonce implementaci napsat přímo v enumu a switch tak úplně vynecháte.

[Heron]

Suit.valueOf(nieco)

Přiznám se, že o tomhle jsem nevěděl. Dřív, ještě než v javě enum vůbec nebyl, jsem si vytvářel třídy napodobující enum podobně jak jsem naznačil nahoře. Teď už chápu tvé rozhořčení. Holt na to nemám tolik času kolik bych si představoval.

[Filip Jirsák]

Vždyť jsem to psal pod tou zprávičkoou – kdo chce switch pro Stringy, nezná pořádně enum

[Heron]

Zprávičku jsem nečetl, další mínus

[Filip Jirsák]

Z návrhů považuju za užitečný jenom multi-catch, v diskuzi pod zprávičkou už jsem psal, proč je podle mne switch na Stringy zbytečný. Vůbec nechápu, proč byly v souvislosti s properties v anketě zrovna tyhle dva (zbytečné) návrhy, a vůbec nebyl zmíněn návrh pro properties daleko užitečnější – přístup k reflexním údajům o properties kontrolovaný kompilátorrem už v době překladu. Třeba Trida.properties.jmeno.getPropertyName(), Trida.properties.jmeno.getGetter() apod. To se sice dá obejít také pomocí enumů, ale chybí tam ta podpora kompilátoru.

[Michal Vyskočil]

Nechápu, proč by mělo properties a [] představovat porušení OOP*. Vždyť i v takovém C++ se pro [] interně volá příslušná metoda. A v Javě by dávalo perfektní smysl označit metodu pomocí anotace tak, že se kód list[12] převede na list.get(12) (nebo foo.bar = "spam" na foo.getBar("spam")). Jen to bude přehlednější.

A typedef, alias lokální jmenné prostory? No, každý, kdo někdy pracoval s kódem, kde se vyskytovalo třeba org.apache.xalan.xsltc.runtime.Node a org.w3c.dom.Node dohromady, by s tebou rozhodně nesouhlasil. Mít možnost si lokálně pojmenovat jednu třídu jako ApacheNode a druhou jako DomNode je k nezaplacení. Pochopitelně to nic nemění na tom, že třídy stále mají svoje kanonická jména, takže luštění podivných jmen nehrozí.

* a to nemluvím o tom, že termín OOP znamená - OOP je to, co za OOP označuje můj programovací jazyk.

[happy barney]

+1, až na ^getBar^setBar^

[finc]

Co se tyce toho peoperties a [], tak mi prijde, ze to jde do prilis velke abstrakce. Jestli je pro nekoho problem psani settru gettru, tak nejspise pouziva spadne IDE :) Navic, obcas se stava, ze dany setter ci getter neobsahuje jen nastaveni a vraceni, ale take nejake dalsi "potreby". Ve finale by to vypadalo tak, ze polovinu budu mit pomoci property a polovinu pres vlastni settery, gettery. Ne, to se mi nelibi.

typedef mi prijde jako hrozna opicarna. Prikaz import ma sva jasna specifika. Jak pri definici, tak pri vyvoji, bych stale musel davat pozor (stale cucet, jak je to v importu) na vlastni definovana jmena. Navic to, ze v jedne tride pouzivam vice trid se stejnym nazvem, muze take znamenat 2 veci: 1. bud neumim OOP a vytvarim 1000 strankove tridy, 2. nebo do dane tridy cpu funkcnost, ktera do ni z konceptu nepatri. Ale jak rikam, je to kus od kusu. Kazdopadne, jsem proti, proti proti typedef! :)

* je snad jasny koncept, jak se maji chovat objekty a jak se ma "cist" objektove orientovany kod ... to, ze jazyky jako PHP, ktere predavaji objekt hodnotou a nikoli odkazem a nazyvaji to OOP, jeste neznamena, ze to OOP je

[happy barney]

typedef mi prijde jako hrozna opicarna. Prikaz import ma sva jasna specifika. Jak pri definici, tak pri vyvoji, bych stale musel davat pozor (stale cucet, jak je to v importu) na vlastni definovana jmena.

používate špatné IDE

Navic to, ze v jedne tride pouzivam vice trid se stejnym nazvem, muze take znamenat 2 veci: 1. bud neumim OOP a vytvarim 1000 strankove tridy, 2. nebo do dane tridy cpu funkcnost, ktera do ni z konceptu nepatri.

alebo človek používa neslnečné knižnice (presne ako v uvedenom príklad).

* je snad jasny koncept, jak se maji chovat objekty a jak se ma "cist" objektove orientovany kod

v tomto jedinom máte pravdu, preto java nie je objektový jazyk

[Daniel Kvasnička ml.]

Navic, obcas se stava, ze dany setter ci getter neobsahuje jen nastaveni a vraceni, ale take nejake dalsi "potreby".

V tom pripade doufam, ze to nepojmenovavas getProperty() ...to bych te jako imaginarni uzivatel tveho API vlastnosrucne uskrtil

[ajikdpoe]

K tym properties - ja javu nepouzivam len preto lebo properties nepodporuje, a dokial ich podporovat nebude tak na javu nemienim prechadzat. Properties je pre mna jednoducho killer feature ktoru musi jazyk podporovat (som vyznavacom "black box" objektov a k tomu sa properties hodia dokonale). Inak implementacia je naprosto trivialna, vo vacsine pripadov sa to robi este na urovni preprocesora takze s implementaciou by nemal byt problem.

[podlesh]

U properties je především problém, že není jasné co to vlastně jako má být.

Například to co má C# bych rozhodně nechtěl. To hlavní (ušetření zápisu getteru/setteru) to nemá, zato je tam společná syntaxe pro přístup k fieldu a k property (a to bych zase nechtěl).

[Filip Jirsák]

Jak tak pročítám ty diskuze, přemýšlím o tom, v čem vlastně všichni ti programátoři javovský kód píšou. A vypadá to na vi, ne-li ex. Pak bych měl ale jednu dobrou radu – přestaňte požadovat syntaktický cukříček, a raději začněte používat nějaké normální IDE. Pohodlí při psaní kódu se zvýší několikanásobně víc, než kdybyste Javu pocukrovali celou.

Jak vypadá v IDE přečtení nějaké property? Napíšu jméno proměnné, tečku, get, zmáčknu Ctrl+mezerník a property si vyberu. Jak je její název dlouhý mne netrápí, protože si ho stejně nepamatuju a nepíšu ho, ale vyberu si ho ze seznamu. A jak by to vypadalo nově? Pořád chci číst property, napíšu jméno proměnné, tečku – a tím jsem skončil, nemám jak dát IDE najevo, že chci property ke čtení. Takže IDE mi vylistuje všechny fieldy, všechny metody, všechny properties (i ty jen pro zápis), a hledej. To je jednoznačně zhoršení proti současnému stavu. Samozřejmě, že je možné zavést v IDE nějakou novou klávesouvou zkartku, která mi vylistuje jenom properties ke čtení – jenomže to je potřeba se zase učit něco nového, v každém IDE to bude jinak… Takže k čemu má ten syntaktický cukr sloužit? Aby bylo psaní kódu pracnější?

[thingie]

Proč IDE. Tohle mají zvládnout v nejhorším nějaká makra v tom jazyce.

[Ladicek]

Proč IDE.

Protože IDE slouží k psaní. Zatímco zdrojový text ke čtení.

[Filip Jirsák]

IDE slouží k vývoji. Třeba čtení zdrojáků Javy s IDE je daleko pohodlnější a rychlejší, než jejich čtení obecným editorem a správcem souborů.

Jinak já jsem v tom komentáři měl původně editor vim, pak jsem to měnil na vi, protože by byla urážka vimu tvrdit, že takovéhle základní věci neumí.

[finc]

Souhlas. Take si nemyslim, ze by bylo tezke vytvaret settry ci gettry. Navod pro Netbeans:

class Test {
   private String pozdrav;

   // zde je kurzor ... nyni Alt+Insert ... vyber pro setter, getter, obe, ci konstruktor s danym parametrem..
}

Pro lidi, co si s Javou jen nehraji, ale pracuji s ni tak, ze je zivi musi takove veci prece znat. Pouziti IDE je naprosto samozrejma vec. Samotna code-completion neni jen na urovni java kodu, ale treba i na urovni jsp, jsf, xml, atd. Proste hromada pluginu + nejake ty zkusenosti.

Osobne nevim, jak by fungovalo nasledujici:

class Test {
   public String pozdrav;
}
test.pozdrav;
class Test {
   private property pozdrav;
}
test.pozdrav;

Ma i IDE ukazovat co to prave je, co je ke cteni, co k zapisu? Co kdyz nekdo tvori tridy "Messenger" (napr. Point.x, Point.y)? To, ze nejaky jazyk ma neco, co Java nema, NEZNAMENA, ze je NUTNE to miti v Jave take.

[Filip Jirsák]

To, ze nejaky jazyk ma neco, co Java nema, NEZNAMENA, ze je NUTNE to miti v Jave take.

Zvlášť když je JVM otevřená dalším jazykům (třeba Groovy) – ať jsou klidně další jazyky které se budou kompilovat také do Java bytekódu, ať používají JVM, ať se klidně bytekód rozšíří o možnosti, které budou těmhle jazykům vyhovovat. V nějakém „skriptovacím“ nebo spíš prototypovacím jazyce, ať klidně jsou uzávěry, zkrácená definice hash-tabulek, property – ale přece to nemusí být všechno v jazyce Java, který prostě je postaven jinak. Vždyť by ten jazyk za chvíli vypadal, jako když pejsek a kočička vyřili dort. Jedno PHP už existuje a není potřeba ho vynalézat znovu… Já chápu, že je lákavé využít možností, které nabízí JVM a spousta javovských knihoven i pro lidi, kterým je bližší programování ve stylu různých mišmaš skriptovacích jazyků, ale to se lépe zařídí dalšími jazyky kompilovatelnými do JVM bajtkódu.

[Ladicek]

Teď mě napadá jedna věc, kvůli které bych byl zásadně pro automatické generování getterů a setterů překladačem na základě anotací @Get a @Set. A to je (fanfára!) setter-based injection. Mít ve třídě X setterů jenom kvůli dependency injection je fakt ptákovina (a X klidně může být > 1, když jde o nějakou fasádu nebo jak se tomu říká). Stejně tak udržovat povětšinou prázdné gettery a settery aktuální, když přidávám a odebírám vlastnosti, je opruz (něco řeší refaktoringy, ale ne všechno).

Jediná nevýhoda, co mě napadá, je, že uživatel by volal getter, který ve zdrojovém kódu vlastně není. Ale to právě krásně řeší IDE

[podlesh]

Samozřejmě, naprosto souhlasím.

Ale jak jsem již psal, jsou různé představy a například "C# way" je naprostý opak.

[finc]

Anotace jsou take pekne peklo. Budme radi, ze se necpou uplne vsude. Az bude hotova nova specka na web-beany, kterou pise Gavin King, jsem zvedavej na to, co si lide budou myslet o anotacich. Jiz v dnesni dobe naleznete hromady anotaci, ktere kod jen zneprehlednuji, delaji z obycejnych POJOs plnokrevne komponenty, ktere se pak daji pouzit pouze tak, ze na classpath nahazim milion knihoven. Anotace by mely byt urceny jen pro konecne komponenty, ktere jsou primo spjaty s danou vrstvou. Staci, ze mame anotaci pro zjisteni prepisu metody z rodice. Vic bych tam v teto urovni necpal.

[Ladicek]

Já s deklarativním přístupem nemám problém. Navíc používání anotací (většinou) pěkně vyhovuje principu lokality.

[Ladicek]

IDE slouží k vývoji. Třeba čtení zdrojáků Javy s IDE je daleko pohodlnější a rychlejší, než jejich čtení obecným editorem a správcem souborů.

Ale jistě. Beru zpět IDE slouží k psaní, chtěl jsem říct k psaní slouží IDE. Je mi jasné, že krom toho taky k řadě dalších věcí.

[thingie]

Takže mít lepší syntaxi na datové struktury je zbytečné, protože v IDE napíšu třeba Map m = { 1 => "Foo", 2 => "Bar" }; a to si to přeloží do Javy a pak už nic? Nějak nevidím důvod proč něco takovýho musí mít každé IDE vlastní a nemohlo by existovat na úrovni jazyka.

[Filip Jirsák]

A opravdu se takovéhle konstrukce používají tak často, aby stálo za to zavádět novou konstrukci do jazyka? Nebo se to ve skutečnosti používá jenom pro testování, kdy programátor potřebuje mapu naplnit testovacími daty, než naprogramuje jejich načítání z externího zdroje? Podle mne spousta těch navrhovaných věcí opravdu jenom taková cukrlátka, kde kdo se nechá nachytat a tvrdí, že to chce (proč ne, když to dávaj zadarmo…), ale když by si měl odpovědět na otázku, kdy naposledy by zrovna tuhle funkci využil – tak zjistí, že vlastně nikdy.

[thingie]

Ale jistě, že využil.

[Filip Jirsák]

A to je jenom teorie, nebo byste dokázal teď vzít nějaký zdroják v Javě, na kterém zrovna děláte, a tam ukázat místo, kde byste tu možnost využil, mělo by to tam logiku, a jiné řešení by bylo horší?

[thingie]

Já zrovna na žádném zdrojáku v Javě nedělám, právě proto, že tohle a spoustu dalších věcí neumí. Chci tohle dělat teď (a dělám) a ne až (jestli) se to uráčí přidat do Javy, žeano.

[Filip Jirsák]

V tom případě by možná bylo lepší pátrat po jiném jazyku pro JVM (třeba Jython, Groovy), než se snažit zmrzačit Javu tak, aby už nevyhovovala ani těm, kterým vyhovuje nyní, ale zároveň ještě nevyhovovala ani vám podobným, kterým vadí, že Java není Python/Perl/Lisp…

[thingie]

Já nepotřebuju aby to byl nějaký jiný jazyk pro JVM, mně je po JVM houby, jsem spokojený s tím co mám. Ale mám skoro stejné důvody jako vy. Až se mi dostane do ruky nějaká Java co budu muset číst či snad do ní ještě psát (a to se stane), tak fakt nechci zkriplenou dementní obludu jako jsou všechny Javy <= 6.

[Kyosuke]

Jak si Tě tak čtu, tak mě napadá ten vtip o tom orlovi, co žil mezi slepicemi a neuměl létat, protože ho nenapadlo, že by vůbec mohl. Ano, je možné, že v kontextu Javy to moc velký smysl nedává. Ovšem to je asi tím, že takovým vlastnostem jazyka dává smysl synergie s ostatními vlastnostmi, třeba schopnost jazyka (rozumně) pracovat s kódem jako s daty a naopak, a to Java nemá (JVM už ano, ale to je něco trošku jiného), nebo readable reprezentace objektů (ne ad-hoc serializační formát, ale standardizovaná reprezentace použitelná jako jakýkoli jiný literál). To ale neznamená, že by to bylo venkoncem k ničemu.

[Ladicek]

Řeč snad byla o properties, tak proč sem taháte hezčí syntaxi pro inicializaci mapy? A kde jsou hranice?

Osobně nemám nic proti literálům pro seznamy a mapy (btw jaké třídy je mapa ve vašem příkladu?), ale k operátorům pro přístup k jejich prvkům už bych byl podezřívavý a něčemu, jako je LINQ, bych se vysloveně vzpouzel. Stejně jako nativní syntaxi pro XML, na kterou autor blogspotu pozapomněl.

[thingie]

Tohle s tím souvisí a zůstavat jenom u nějakých properties by byla škoda.

Jaké třídy? Map importovaný z kolekce. Generika ať si kompilátor odvodí sám. Samozřejmě, celý je to polovičatý, lepší by bylo dát prostředky jak dělat takové věci přímo do jazyka, ne jenom vyřešit pár nejbolavějších případů, i když i to je lepší než nic.

[Ladicek]

Typové parametry si překladač odvodí už teď (bohužel ne pro konstruktory), mě zajímalo, jestli se za vaším zápisem skrývá HashMap, TreeMap nebo třeba ConcurrentHashMap nebo co vlastně

Mimochodem hezký je koncept builderů v Groovy.

[thingie]

Nebál bych se čekat, že pro půlku světa programujícího v Javě mezi konkrétníma implementacema mapy neexistuje rozdíl, takže je to asi dost jedno, ne?

[Ladicek]

To se klidně dá obrátit: jestli pro tu druhou půlku javovského světa rozdíl mezi různými implementacemi map existuje (a on je dost podstatný), tak to určitě jedno není.

[Filip Jirsák]

Samozřejmě, celý je to polovičatý, lepší by bylo dát prostředky jak dělat takové věci přímo do jazyka, ne jenom vyřešit pár nejbolavějších případů, i když i to je lepší než nic.

K čemu by bylo dobré udělat z Javy druhé C++?

[podlesh]

Samozřejmě, celý je to polovičatý, lepší by bylo dát prostředky jak dělat takové věci přímo do jazyka, ne jenom vyřešit pár nejbolavějších případů, i když i to je lepší než nic.

K čemu by bylo dobré udělat z Javy druhé C++?

Já myslím že byl míněn LISP Tedy doufám, možná jsem naivní...

[Ladicek]

Však co, v Perlu jsou taky jenom hashe a pole, a stačí to. Když jsem jeden čas dělal reporty, vysloveně jsem psal Perl v Javě

[podlesh]

No, i v perlu by se TreeMap hodila... a což teprve LinkedHashMap.

[happy barney]

Red-Black (TreeMap)
LLHash (LinkedHashMap)

[podlesh]

To ovšem není to o čem se bavíme.

I když, AFAIK, by toho dosáhnout šlo.

[thingie]

Asi, spíš, tu konstrukci na mapy člověk v C++ asi taky nevykouzlí.

[thingie]

Co je na Javě lepší bez toho?

[Filip Jirsák]

Třeba právě to, že tyhle věci neumožňuje. Takže je to jednoduchý jazyk, jehož konstrukce zvládne každý (až na generiky, které do téhle Javy moc nezapadají). Díky té jednoduchosti může být taky dobře a snadno v reálném čase analyzován zdrojový kód, což umožňuje poskytnout programátorovi při programování velkou podporu. Spousta věcí na vyšších úrovních je zase dána konvencemi, takže pokud programátor dělá něco netradičně a píše se mu to špatně, mělo by ho to vždy upozornit, jestli problém, který řeší, uchopil správně. To všechno nejsou výlučné vlastnosti Javy, ale Java je na tom v tomto směru líp, než jiné jazyky. A jiné jazyky mají zase svoje výhody – Java neumožňuje psát nízkoúrovňové věci využívající konkrétního hardwaru, v Javě píšete nízkoúrovňově nad JVM. Neumožňuje parametrizovat program v době překladu, jako to umožňují makra v C nebo šablony v C++. Neumožňuje pracovat bez používání typů nebo datových struktur, jako to umožňují skriptovací jazyky. Neumožňuje psát minimalistické konstrukce, jako to umožňuje Perl. Ale každý z těch jazyků se přeci hodí k něčemu jinému.

[thingie]

Zajímalo by mě, kde lidi přišli na to, že ty věci o kterých se tu bavíme jsou obtížné a ten jazyk by pak nebyl jednoduchý a někdo ho nezvládl.

[Michal Vyskočil]

Neumožňuje pracovat bez používání typů nebo datových struktur, jako to umožňují skriptovací jazyky.

List foo = new ArrayList();
foo.add((Object)bar);

Tak tomu já práce s použitím typů (spíše tříd, Java práci s typy nemá) neříkám. Object v Javě je ekvivalentem void* v C/C++ a jako takové by mělo být používáno výjimečně a ne pro práci s kolekcemi. Právě generika posilují typovou kontrolu, což je v případě Javy jednoznačně žádoucí i s ohledem na filozofii a určení jazyka.

BTW: [] a properties jsou navrhovány pro zjednodušení jazyka. Nechápu, jak by mohly v konečném důsledku znamenat jeho zesložitění. Při rozumné implementaci za pomoci anotací není třeba dělat velké změny a sémantika nových i stávajících operací zůstane naprosto stejná. Ano, Perl a jeho 10 způsobů, jak udělat jednu věc je odstrašující, ale ani v Javě si na akademickou eleganci a ortogonalitu jazyka stejně nehrajeme

[Kyosuke]

Právě generika posilují typovou kontrolu, což je v případě Javy jednoznačně žádoucí i s ohledem na filozofii a určení jazyka.

Hmm, posilují? Asi tak, jako ji dříve posilovala kovariantně parametrizovaná pole?

[Michal Vyskočil]

Kdybych věděl, co je to to kovariantní tentononc, tak bych ti možná mohl odpovědět.

[thingie]

Strašná blbost to je, jenom to zní drsně

[Kyosuke]

Ty máš co povídat, haskellisto.

[Filip Jirsák]

Tak tomu já práce s použitím typů (spíše tříd, Java práci s typy nemá) neříkám. Object v Javě je ekvivalentem void* v C/C++ a jako takové by mělo být používáno výjimečně a ne pro práci s kolekcemi. Právě generika posilují typovou kontrolu, což je v případě Javy jednoznačně žádoucí i s ohledem na filozofii a určení jazyka.

Ano, generika posilují typovou kontrolu a Java je lepší s nimi než bez nich. Ale nepodařilo se je do Javy implementovat tak, aby vypadala jako její „přirozená“ součást – vizte například nekompatibilitu generik a polí nebo neexistenci reflexe. Myslím, že v tomto směru bylo obětováno zpětné kompatibilitě bajtkódu příliš mnoho.

BTW: [] a properties jsou navrhovány pro zjednodušení jazyka. Nechápu, jak by mohly v konečném důsledku znamenat jeho zesložitění.

To, co bylo zmíněno v anketě v souvislosti s properties není žádné zjednodušení. Property declaration je jednoduše znovu zavádění atributů tříd do jazyka, který atributy tříd už má. Jenomže o atributech tříd si každý v souvislosti s Javou přečte, že se nemají používat, protože zapouzdření. Tak se vymyslí znovu to samé, ale bude se tomu říkat jinak. To je opravdu vynález…

A property access jednak zhoršuje možnost nápovědy IDE, jednak je zaměnitelné s přístupem k atributům tříd. Takže nově by musel programátor každého přiřazení kontrolovat, zda jde o property nebo field, a v případě, že jde o property, očekávat různé výjimky – ať už PropertyVetoException, nebo nějaké obecné; a také další záludnosti spojené s voláním metod – zámky, synchronizaci… Opravdu nevidím důvod, proč před programátorem skrývat, že volá metodu, když z toho nemá žádný prospěch – jméno té metody a závorky stejně doplní IDE, takže nemá smysl se bavit o tom, jestli to ušetří dva znaky.

[happy barney]

zmysel to imho má napr pri operátoroch +=, -=, ... tam to ušetrí oveľa viac, hlavne, ak je property výsledkom reťazca volaní. A aký silný nástroj by to bol s overloadovaním operátorov (popr možnosťou definície svojich vlastných)

[Filip Jirsák]

Ale operátory += a -= jsou definovány jenom pro některé primitivní typy a += pro String, pro objekty nejsou definovány.

Ano, teoreticky by opravdu bylo možné Javu rozšířit o vícenásobnou dědičnost, přetěžování operátorů, makra, šablony – ale není už jazyků, které tohle umí, dost? Mně to pořád připadá, jako by si někdo stěžoval, že příkaz cat by vlastně měl mít aspoň řádkový editot textu, no samo o sobě by to vlastně nedávalo moc smysl, ale kdyby se k tomu přidělal i celoobrazovkový editor, podpora externích příkazů, maker, klávesových zkratek – a pak už by z catu byl konečně pořádný editor.

Takže stejně, jako se cat blbě používá jako textový editor, bagr se těžko používá jako vozidlo pro dopravu osob, tak se i Java blbě používá jako jazyk pro programy, kde je potřeba vícenásobná dědičnost, šablony a přetěžování operátorů. Akorát mám pořád neodbytný pocit, že to není problém Javy, ale těch, kteří se jí pokoušejí takhle používat. Co je vede k tomu, že chtějí používat zrovna Javu? To má tak líbivý název, nebo čím to je?

[happy barney]

Ano, teoreticky by opravdu bylo možné Javu rozšířit o vícenásobnou dědičnost, přetěžování operátorů, makra, šablony – ale není už jazyků, které tohle umí, dost?

... java nie sú len desktop/server obludy, java to je aj java ME. Tam už ľudia javu nútený používať sú.

ok, pre ilustráciu, zaveďme do javy hypotetický operátor .=

object.a (1).b (2).c .= method ();

// vo význame
object.a (1).b (2).c = object.a (1).b (2).c.method ()

[Michal Vyskočil]

Ano, je fakt, že jsou generika v Javě napůl cesty. Proto snad nikdo neodporuje jejich pořádné implementaci, protože imho měla být součástí jazyka už dávno. Proto je moc dobře, že MS vytvořil .NET a donutil Sun sestoupit z oblačných výšin dokonalosti svého výtvoru.

Souhlasím, že jsem se nepodíval na článek a pořád jsem manipuloval se svojí představou properties

class Foo {
   protected int bar;

   @Property
   public int getBar() { return this.bar; }
   @Property
   public void setBar(value) { this.bar = bar; }
}
// ...

Foo foo = new Foo();
foo.bar = "a";

To, co bylo popsáno na javapolis je divné. Ale já bych šel ještě dál a public u členských prvků tříd úplně zakázal

BTW: ale úplně nejvíc mi chybí dopředná kompatibilita knihoven. Pokud potřebuji kód přeložit s novější verzi JDK, musím obvykle doplnit nové metody, které přibyly do rozhraní jenom proto, aby to šlo zkompilovat. Parametry source a target tohle vůbec neovlivňují. Takové @Since(1.5) by mi vytrhlo trn z paty

[Filip Jirsák]

BTW: ale úplně nejvíc mi chybí dopředná kompatibilita knihoven. Pokud potřebuji kód přeložit s novější verzi JDK, musím obvykle doplnit nové metody, které přibyly do rozhraní jenom proto, aby to šlo zkompilovat. Parametry source a target tohle vůbec neovlivňují. Takové @Since(1.5) by mi vytrhlo trn z paty

Protože source a target ovlivňují jenom verzi jazyka, ale ne verzi runtime knihovny, proti které se kompiluje (což je trochu zvláštní, a nakonec jsou proto tyhle parametry k ničemu).

Podle mne to ale není problém ani knihoven, ani jazyka, ale toho, že se upravují rozhraní (v runtime knihovně), místo aby se oddědilo rozhraní nové. Osobně jsem to zaregistroval jenom u XML DOMu, ale když jsem to tenkrát zjistil, měl jsem pro autory té úpravy rozhraní jenom samá nepublikovatelná jména.

[jk]

Ja myslim ze property a property access je uzitecna vec. Property se chovaji stejne jako settry/gettry, pokud v budoucnosti zjistim, ze je potreba udelat vic nez nej nastavit/precist promenou, tak to muzu snadno doplnit aniz bych musel prepsat zbytek kodu co to pouziva. Pouzivani get/set akorat zneprehlednuje kod.

[happy barney]

btw, keď vynecháte z javy "maďarský prízvuk" (get/set), tak aký rozdiel medzi get/set-rami a property ?

[cronin]

Pri procitani vysledku z javapolis, jsem zacal premyslet o tom, zda dane featury do javy skutecne chci, ci nikoli.

Ako clovek, co v Jave programuje takmer denne, mozem povedat, ze NASTASTIE to, co v Jave bude a co nie h...o zalezi od toho, co sa pise v Tvojom blogu a v desiatkach podobnych na celom svete. Podobne blogy neobsahuju nic viac a nic menej ako "own truth" ich autora.

[finc]

Vsak o tom jsou zapisky do blogu, ty nemeni nic na tom, jak se rozhoduje comunity process :) Jedna se ciste o muj nazor, na ktery jsem chtel znat i nazor ostatnich. Navic, proc na javapolis byly dane whiteboardy? Mozna proto, aby udelali pruzkum bojem. Nemyslim, ze by sun implementoval neco (az na vyjimky), co vetsinova komunita vyvojaru nechce.

[Saljack]

Ne možná se v ní dobře programuje ale jinak je ten největší šmejd co znám. Javová aplikace je fakt hroznej balast cokoliv jenom ne javu

[finc]

+ 1000 Konecne to nekdo rozsekl! Tomu rikam padny argument! ;)

[Daniel Kvasnička ml.]

Javová aplikace je fakt hroznej balast

Myslis tim i AbcLinuxu? To by se Leosovi taky nemuselo libit ...