Integer.setValue() hvorfor ikke?

Alle de der "halv simple data type" objekter: Integer, Doubl, String etc. er
immutable.

og hvorfor ?

http://www.javaworld.com/javaworld/javaqa/2000-06/01-qa-0602-immutable.html
http://www.artima.com/intv/gosling313.html

->arne_v: Ja, det er de. Men findes der ikke et sæt af klasser, der er mutable? I mange situationer har man dette behov, jf. mit simple eksempel.

->arne_v: Selveste Gosling er selvfølgelig et vægtigt argument, men alligevel :-). Der er gode grunde til, at nogle klasser er immutable, men i andre situationer har man netop det modsatte behov, og det pudsige er vel, at det ikke er svært selv at lave sådanne klasser, f.eks. noget med:

public class MyInteger {

    static class Integer {
       
        private int i;
       
        public Integer(int i) {
            this.i=i;
        }
       
        public void setValue(int i) {
            this.i=i;
        }
       
        public int getValue() {
            return this.i;
        }
    }

Jeg har lidt svært ved lige at se hvor man vil have brug for den funktionalitet.

Integer er jo netop kun en object wrapper omkring int.

int har ikke den funktionalitet.

Og jeg vil finde det meget tricky at:

x.setValue(7);

og

x=7; // 1.5 auto boxing

har forskellig funktionalitet.

Men ja - de kunne have lavet javax.mutable.Integer etc. - jeg tror bare ikke
at efterspørgslen er der.

->arne_v: Jo, der er anvendelser, hvor det efter min mening nærmest er nødvendigt, nemlig når den samme behandling gentages mange gange.

Eks.: Antag at man læser nogle informationer (array af int's) fra en fil eller socket. I programmet gennemgår det indlæste en forholdsvis kompliceret og tidskrævende behandling inden et resultat kan vises. Behandlingen kunne f.eks. være en eller anden permutation af det indlæste, som ikke afhænger af værdierne af det indlæste (vigtigt!). Permutationen er altså den samme hver gang.

Antag at man har en metode permutation(Integer[] i), som igen afleverer et resultatet på formen Integer[], og hvor altså permutationen ikke afhænger af værdierne. Da Integer er immutable vil et program se således ud:

Integer[] a;
do {
  // læs værdier ind i 'a' fra fil/socket
  ...
  Integer[] b=permutation(a);
} while (true);
// arbejd videre med 'b'

Da permutation()-metoden er tidskrævende er denne løsning ikke hensigtsmæssig. Hvis Integer derimod var mutable, kunne permutation() flyttes uden for løkken:

Integer[] a;
Integer[] b=permutation(a);
do {
  // læs værdier ind i 'a' fra fil/socket
  ...
} while (true);
// arbejd videre med 'b'

Herved er funktion og indhold adskilt. Funktionen udføres kun én gang, og indholdet kan så udskiftes hele tiden, uden det er tidskrævende.

Et andet eksempel er løsning af komplicerede differtialligninger, hvor man skal tabellere løsningen i mange punkter. Hvis f.eks. en numerisk metode er 1 sek. om at finde løsningen i et punkt, og ligningen skal tabelleres i 1 mio. punkter, vil det være særdeles tidskrævende arbejde. Her kan det (hvis det kan lade sig gøre) være hensigtsmæssig at bruge måske 5 min. på at finde den symbolske løsning på ligningen (hvis man har værktøj til dette) og derefter blot sætte værdierne ind i denne.

jeg kan godt se pointen i dit eksempel, men jeg tror at de4t er for sjældent til at
SUN vil tilføje noget til Java

(jeg kan ikke helt se hvordan differential ligningerne hænger sammen med topic)

->arne_v: Det er så heldigvis fredeligt selv at lave mutubale klasser, så man kan klare sig med disse, altså en slags "wrapper-wrapper" klasser.

I mit eksempel, hvor jeg flytter permutationen uden for løkken, kan man sige, at jeg har flyttet formlen uden for løkken og blot bruger løkken til at sætte ind i den fundne formel. Dette er parallellen til differentialligningerne: Hvis først man har løst differentialligningerne symbolsk/algebraisk, kan man tabellere løsningen ved bare at sætte ind i den fundne formel.

Et helt ekstremt eksempel kunne være styring af moderne jager-fly. Så vidt jeg ved, er disse så ustabile at flyve, at piloten kun kan flyve dem vha. computer-hjælp. Flyets reaktioner i forhold til hastighed, retning, højde, vindforhold m.m. kan formentlig beskrives vha. komplicerede differentialligninger, og løsningen af disse er afgørende for, hvordan flyet skal styres. Hvis den numeriske løsning af disse differentialligninger ikke kan løses hurtigere end, hvad der er behov for i forhold til flyets reaktioner, vil flyet måske ikke kunne flyve. Her forestiller jeg mig, at hvis man først (på landjorden) en gang for alle har løst differentialligningerne symbolsk/algebraisk, vil løsningen i luften kunne findes lynhurtigt ved direkte at sætte ind i den fundne formel. Dette vil være afgørende for flyets evne til hurtigt at reagere og måske overhovedet flyve.

Nok snik-snak - smid gerne et svar :-)

Jeg ville nok lade MutableInteger wrappe int og ikke Integer, men ja det er ret simpelt.

Og et svar.

->arne_v: Ja int er vel tilstrækkeligt her, enig.