Skuste pozriet tuto diskusiu, mozno Vam najdete odpoved na niektore
otazky (nazov je Java 7 ale je to primarne o Java 8 ):
http://medianetwork.oracle.com/media/show/16796
Pekny den
Radovan
2011/7/14 x y jsoale...@gmail.com:
Viete mi niekto povedat preco konecne nedaju do javy z dovodu
S těmi property absoluteně souhlasím. Stavím aplikace masivně založené na
beanech a hlídat gettery a settery je opravdu jedním slovem vopruz.
Možnost o které dost uvažujeme je psát beansovské classy jako GroovyBeans.
Libor
BTW: To zase bude flame na tři týdny :-)
2011/7/14 x y
Preco nie su properties, mi nie je jasne a AFAIK v Jave 8 nebudu. Java
je uz zamrazena sama v sebe, lebo spatna kompatibilita je nutnost a
kazda dramaticka syntakticka zmena je zvazovana natolko, ze niekedy je
nemozne ju s kompatibilitou sklbit (.NET ma v tomto vacsiu flexibilitu)
Ruinujuce a
Properties mi osobně vůbec nechybí. Kdysi jsem řešil ještě v Borland Delphi
jeden problém a než jsem zjistil, že v properties je změněná jedna hodnota
naprosto divně, přestože být neměla, trvalo to několik dní.
Pokud jde o jednoduchost psaní, tak Idea se mi o gettery a settery postará
sama. Pokud
Property tak jak jsou řešeny v projektu Lombok podle mého názoru do jazyka
nepatří. Používají totiž anotace a anotace jsou v Javě prostředek pro
specifikaci dodatečné informace o zdrojovém kódu. Proto by bylo divné,
kdyby anotace měnily sémantiku zdrojového kódu.
O jakém balastu to mluvíš?
Rozmyslam o situaciach, ked potrebujete mat typesafe pristup k
properties (napr. wicketovske bindingy modelu na bean by sa zjednodusilo).
Ci si myslite, ze sa to da riesit plug-inmi pre IDE?
On 14. 7. 2011 12:07, Zdeněk Troníček wrote:
Property tak jak jsou řešeny v projektu Lombok podle mého
Ahojte,
Len taky moj nazor. Ja to s gettes/setters nevidim tiez nejak zle. Ved dnes
ich IDEcko dokaze generovat v priebehu jednej klavesovej skratky. Zase tie
getters/setters ma o tolko casu neuberaju. Pisu sa len raz a pri citani ich
clovek uz berie ako samozrejmost. V Scale je naprikald
Já osobně jsem také zastáncem kombinování různých jazyků.
Nezapomínejme že Java je (vzhledem k JVM) low-level jazyk, troufal bych si
ho přirovnat k C na nativních platformách. Co je v Javě napsáno, to je
poměrně přímočaře vyjádřeno do bytecode. Žádný jiný tak nízkoúrovňový jazyk
na JVM není,
Cau,
podle me gettery a settery nechat a jen pridat do eclipse pridat
podporu /* name=generovaneGettery colapsed=true type=bean*/ jako
castecne v netbeans a pripadne nejaky plugin co umi trosku lepe
refaktorovat beany prip kontrolovat ze dany blok je validni beana
(set+propertyName) a ne
O jakém balastu to mluvíš? Gettery a settery přece umí každé IDE
vygenerovat a psát p.speed místo p.getSpeed() mi nepřijde jako zásadní
změna. Navíc mnohem důležitější než snadnost či obtížnost psaní je
snadnost či obtížnost čtení (v literatuře se uvádí, že na jedno napsání
připadá až 20
ano ide o citatelnost(to som aj uviedol .. z dovodu sprehladnenia..) a to
prispieva k rychlosti vyvoja, da sa to riesit urcite na urovni IDE, ale ked
uz sa robi radikalny zasah do javy(teda tak ci onak bude s5tne
nekompatibilna) napr. closures, tak nechapem preco tam nedaju tie property,
preto by
Closures budou zpětně kompatibilní. Možná ne ze 100%, ale téměř jistě se
to číslo bude 100 blížit.
Z.
--
Zdenek Tronicek
FIT CTU in Prague
x y napsal(a):
ano ide o citatelnost(to som aj uviedol .. z dovodu sprehladnenia..) a
to
prispieva k rychlosti vyvoja, da sa to riesit urcite na urovni
Myslím, že tu nezazněl jeden veledůležitý fakt. Třídní/instanční
proměnné, kam bych property zařadil (pokud nemá v době kompilace vlastní
metody), nejdou přetížit. Naopak getter/setter jsou normální metody,
kde je OOP přístup aplikován. Vím, že na tyto metody by to být
aplikováno nemělo
13 matches
Mail list logo
