Java™ SE 7 wish list
Peter Ahé egy eredekes Java Dolphin-os whishlistet fogalmazott meg blogjaban. Szamomra egy-ket otlet eleg meredeknek tunik, de van olyan is amit szivesen latnek a 7-es javaban.
"Real closures"
Closures-rol mar tobben irtak. Nekem akkor ez egy uj dolog volt mert az altalam hasznalt nyelvek nem igazan tamogatjak. Tulajdonkeppen kodblokk amit egy fuggveny parameterkent adunk meg. Ertelmezesem szerint annyiban tud tobbet mint egy callback/delegate/anonymousinnerclass hogy a blokkon kivuli lokal valtozokat eleri. Tipikusan azt csinalja hogy egy collection minden elemere meghivja a megadott blokkot, az pedig valamilyen muveletet vegez a kapott parameterrel. Ilyesmit lehet csinalni javaban egy anonymous inner class + final tomb referenciaval, de a dolog lenyege inkabb az lenne hogy egy egyszeru szerkezetet szolgaltat amivel roviden megoldhato a dolog.
Rubyban ezzel sokat szoktak operalni. Python mar kevesbe tamogatja de map/filter + lambda-val lehet hasonlo hatast elerni. Amiota bejott a List comprehension, azota amikor csak lehet mindenki azt hasznalja mert sokkal attekinthetobb.
Nem egy olyan dolog ami nelkul ne lehetne elni, de ha valami atlathato syntaxot talalnak ki neki akkor lehet hogy jo lesz.
"Type aliasing"
pl.: "import java.util.List<String> as StringList;"
Ez csak egy aprosag de jol nez ki. Pythonban is van ilyen bar ott ritkan hasznalom, mert viszonylag rovidek es konnyen megjegyezhetoek a modul es package nevek. Javaban viszont a kacifantosabb nevek -foleg igy genericel kombinalva- leroviditesere jol johet. Mivel ugyis csak importban hasznalhato (remelhetoleg) igy nem ront az olvashatosagon.
"Super packages"
Hmm, nekem nincsenek ilyen igenyeim a packagekkel kapcsolatban, de akik nagy meretu frameworkoket fejlesztenek azoknak lehet.
"Shorthand syntax for declaring properties"
Azaz "property String foo"-bol csinal setter/gettert. Ez ebben a formban nem tudom miert jo nekunk. Egyreszt a legtobb IDE ugyis auto generalja, masreszt ha a setter/getterbe sajat kodot akarok rakni akkor nem hasznalhatom. Max olyan formaban lenne ertelme mint ahogy C#-ban van. De akkor meg szvsz a kezdetektol kellett volna alkalmazni, nem utolag belerakni. Szerintem ez igy felesleges.
"Array syntax for collections"
"How sweet is this:
final map = new HashMap<String, Integer>();
map["one"] = 1;"
Na igen, ez tok jo lenne csak sztem egyaltalan nem illik bele a java nyelvezetebe.
"Shorthand syntax for declaring local variables"
Ezen mar akkor is enyhen ledobbentem amikor meglattam hogy C#-nal ilyet akarnak.
Vagyis lokal valtozokat tudok ugy deklaralni hogy nem irom ki a tipust mert az az ertekadas alapjan dol el. Erre tobbfele javaslat is van.
JavaScript-re emlekezteto syntax: (szerintem ez a legrondabb)
var foo = "bar";
Vagy:
final foot = "bar"; (mivel ha final akkor ugyis csak egyszer tudom inicializalni)
Gosling pedig a kovetkezo syntaxot javasolta:
foo := "bar"; // Valaki mar meg is patchelte azota a javac-t hogy elfogadja ezt az ertekadast. Hat igen, GPL.. :)
A "var"-os nal azonkivul hogy JS-re emlekeztet meg uj keywordot is be kell vezetni. Enumnal is volt ilyen hogy 1.4-es sourcban pl valtozonevkent hasznaltak, 1.5-re nem lehetett egyazegyben leforgatni mert ott mar reserved word. De a legfobb ervem az hogy hulyen nez ki (akarcsak pascal styelos operator) :).
Legeloszor a dinamikusan tipusos nyelvekre asszocialtam de ettol meg nyilvan ugyanugy static typing marad.
(Egyebkent meg a dinamukusan tipusos nyelveknek szvsz nem is az az igazi elonye (ami egyesek szerint nagy hatrany is lehet) hogy nem kell kiirni a tipust hanem sokszor egyszeruen nem is erdekel hogy kinek mi a tipusa. Max az hogy mit tud az illeto objektum. Ha egy file objectnek es egy socket objectnek is van read metodusa akkor nekem az egyforman jo hiaba total kulonbozo a ket objektum. Ugyanugy hasznalhatom anelkul hogy kozos interfacet irnek ra benne a read methoddal. Ezert ritkan is lehet olyat latni hogy isinstance, helyette inkabb hasattr-t hasznalnak. Abba nem mennek bele hogy alkalmas-e ilyen nyelv nagy rendszerek fejesztesere mert ebbe nem tudnek allastfoglalni. (mindenesetre van ra pelda boven). Kisebb programok fejlesztesenel viszont ez nagy mertekben novelheti a produktivitast (masok szerint meg a hibalehetoseget:)).
Visszaterve a javahoz, nem tudom hogy van-e a dolgonak azon kivul haszna hogy nem kell leirni par karaktert. Uj keywordot es operatort meg szerintem hanyagolni kene.
Gondolkodtam hogy en milyen featuret latnek szivesen de nem sok ertelmes dolog jutott eszembe. kack viszont ezt javasolta:
catch( Exception1, Exception2, Exception 3 ) { }
Ezt most max ugy lehet hogy kozos parent-et csinalok nekik es azt kapom el. De vegulis elofordulhat hogy logikailag nem illik bele vmelyik Exception egy bizonyos hiearchiaba de attol meg egyuttesen szeretnem elkapni oket.
Nem vagyok az uj featureok ellen, csak az olyanokat nem szeretem amik rontjak az olvashatosagot, vagy nagyon "hackelhetove" teszik a nyelvet. Ez alatt azt ertem hogy ugyanazt a dolgot tobbfelekeppen meg lehet csinalni, pl egy sorban ugyhogy senki nem fogja erteni mit csinal az a sor, vagy tobben es akkor esetleg atlathatobb lesz. Ha a Closures-nek vmi szar syantox talalnak ki akkor abbol lehet ilyen problema. Az olvashatosagot szvsz a tul sok keywordel, tul sok speci operatorral is le lehet rontani. Szoval szerintem mertekkel kene kezelni ezeket a featureoket.
Scanning java annotations - reflections
2 months ago
