Mikor lesz Java 7?

En is tudtam. Nem nagy kunszt :D

csokker ;))

--
Wir sind erfaßt, sind infiziert,
Jedes Gespräch wird kontrolliert.

Szerintem ez _ronda_, nagyon, főleg a dupla deklaráció, amely igen gyorsan pofáncsapható egy jó irányzott refactorral:

1  private int _pozitiveNumber;
2  public int PozitiveNumber
3  {
4    get 
5    { 
6      return _pozitiveNumber; 
7    }
8    set 
9    { 
10     if (value < 0)
11     {
12       throw new Exception();
13     }
14 
15     _pozitiveNumber = value;
16     ValueChanged();
17   }
18 }

Ez ugyanaz, 4 sorral kevesebb, nincs redundancia, nincs tévedés, hogy mit és mivel használsz, az IDE pedig legenerál ebből a 14 sorból 8 sort:

1  private int pozitiveNumber;
2  public int getPozitiveNumber()
3  {
4    return this.positiveNumber;
5  }
6  public void setPositiveNumber(int value)
7  {
8    if (value < 0)
9    {
10     throw new Exception();
11   }
12   this.pozitiveNumber = value;
13   ValueChanged();
14 }

Ez a hozzáállás miatt nem képeznek már normális fejlesztőket, csak kódlapátolókat.

Mindig kódlapátolókat képeznek, akikből jobb-rosszabb fejlesztő lesz. De abból még nem lett sikeres program, ha egy junior nekiállt optimalizálni. Abból se lett sikeres program, ha egy optimalizálásban tapasztalatlan senior áll neki optimalizálni.
--
http://wiki.javaforum.hu/display/FREEBSD

a destruktor temat mar lefutottuk 1x, nem? ;)

Erre írtam volt:

A kioptimalizálás a JVM dolga, a programozó ne optimalizálgasson feleslegesen, főleg, ha nem is ért hozzá, mert sokszor több kárt csinál, mint hasznot.

Ha az ember optimalizálni akar nyelvi szinten, akkor ehhez kőkeményen tudnia kell, hogy ebből mit csinál a fordító, és mit csinál a JVM, majd mit csinál a JIT. Ha ezekkel nem vagy tisztában, akkor inkább ne is optimalizálj, mert tapasztalataim szerint abból később refaktor lesz.

A felesleges GC futásokat és a memleak gyártó kódokat többnyire a C/C++ irányból érkező programozók ejtik, mivel nem ismerik a GC működését, részben utálják is, és többnyire nem tudják, nem értik, hogy mit és mikor takarít ki, ezért próbálnak maguk takarítani és optimalizálni. Az érdekes egyébként az, hogy ha az ember nem tödődik azzal, hogy optimalizáljon memóriafoglalásra a Java nyelvi szintjén, akkor alig tud olyan helyzetet előállítani, ami memleak jelenséggel jár.
--
http://wiki.javaforum.hu/display/FREEBSD

Optimalizáció témához:
És itt jön elő a toolok ereje. Ugyanis ha használunk kódelemzőket, mint pl.: FindBugs, akkor az kapásból felhívja a figyelmet, ha ciklusban fűzöl össze stringet, hogy használj StringBuilder-t.

Memleak: általam összerakott felvételi Java tesztben szerepel, hogy "Lehetséges -e memory leak Javaban?". Sajnos a válaszadók fele nemet szokott írni.

Eleve úgy mondják, hogy a protected változó tervezési hibára utal (vagy optimalizációra). Nem mintha védeni akarnám a jávát.
----
Hülye pelikán

Az első esetben sem lehetsz biztos benne. pl.:

public void setY(Valami param) { y = param; }

Ezért írtam, hogy "potenciálisan futni fog", egy jelzés a nyelvben, hogy számíthatok akár kivételre is a hívás során.

Tehát a protected láthatóság használata teljesen kerülendő.

Reflection-nel pedig ki tudod olvasni a privát mező értékét is bárhonnan. És? Ettől még a private láthatóság jól jön és lehet rá építeni, csakúgy, mint a protected láthatóságra, amelynek célja az, hogy egy osztályt leszármaztatva hozzá tudj férni mezők értékéhez vagy felül tudj definiálni metódusokat.

A Scala nagyon jó, de mutass Scala alapokon félmillió soros projektet, ha találtál ilyet, akkor mutass közülük olyat, amely nem szenved attól, hogy nincs igazán IDE támogatás, se fejlesztői hozzáértés. :)
--
http://wiki.javaforum.hu/display/FREEBSD

A beépített operátorok nem veszélyesek, mert a többségét aritmetikára használjuk (amire való és amit már minden programozó a matek órái óta tanul, másrészt a legtöbb program nyelvben ugyanazt csinálják). Ez alól kivétel a String összefűzésre használt + operátor. Ez egy tipikus operator overloados dolog és lám mennyi probléma van belőle. Ccsak az itteni beszélgetés közben előjött a String összefűzögetés optimalizáció problémája, azaz, hogy nem világos az egységsugarú programozónak, hogy itt a + új String-et hoz létre és nem az első Stringet módosítja. Pedig, ha nem + lenne, hanem metódus jobban látszana mi történik.
Azaz
String s4 = s1 + s2 + s3;
Tisztán OO megvalósítása:
String s4 = s1.clone();
s4.concat(s2);
s4.concat(s3);
lenne (persze jó hosszú mint a rétestészta). Rögtön látszana, hogy mikor jön létre új String. A StringBuilder-rel pont ezt a működést imitáljuk.

A beépített operátoroknak annyi a felmentésük még, hogy előre definiált darabszámú van belőle és be lehet magolni. Ezzel szemben a user definiált operatorok esetén sose tudod mire számíts.

A beepitett operatorok azert nem veszelyesek, mert elore definialt a szemantikajuk. Mindenki szamara ugyanazt jelentik.

Arra gondoltam, hogy Scala-ban nincsenek primitívek, minden osztály, csak hozzátettem, hogy még a függvények is azok.

Ebben a szálban én a "syntactic sugar"-t egyfajta szitokszóként érzem, mintha azt akarnátok mondani, hogy amit egyszerűbben, tömörebben, átláthatóbban lehet leírni egy nyelven az rossz.
A gépi kódhoz képest egyébként minden "syntactic sugar".

Vegyük például a Java 5 előtti iterator ciklus, kb. így nézett ki:

for (Iterator iterator = list.iterator(); iterator.hasNext(); Object value = iterator.next())

aztán bejött a syntactic sugar:

for (Object value: list)

Szerintem többek között az ilyen syntactic sugaraktól lesz egy nyelv egyszerűbb, jobb, hatékonyabb, mint egy másik.

Mindegy, hogy fű alatt OO, ha használatnál nem annak látszik. Az OO szemlélet nem a gépnek kell, hanem a programozónak.

"Hurrá. Írjuk le egy sorba az összes programot, ezzel mindegyik hibátlan lesz! Hatalmas ötlet. :)"
Tényleg nagy ötlet, szabadalmaztasd! :-)
Egyébként az továbbra sem fog egy "sornak" számítani.

"Sajnos tömörebb - nehezebben olvasható kódban több a hiba is."

A tömörebb kód pont az olvashatóságot javítja, és kevesebb hibalehetőséget ad. Írtam példának az Iterator-os vs. For-each ciklusos példát, illetve a swap-es példát:
Scala:

(x, y) = (y, x)


Java:

Object temp = x;
x = y;
y = temp;


Melyik az egyszerűbb, átláthatóbb? Melyiket könnyebb elrontani? Melyik közé kerülhet új sor, ami ront az olvashatóságán?