Newsgroup: it.comp.java
Titolo: class Calendar

}
perché scritto così in fase di compilazione mi compare il seguente
messaggio:
DataGiorno.java:9: constant expression required
   case data.MONDAY:
                                 ^
1 error
mentre se invece scrivo Calendar.MONDAY non ci sono problemi?
Come mai invece data.DAY_OF_WEEK non dà problemi? In fondo sono entrambi
campi "static int"
Aiut... non ci capisco più niente!!!
Grazie anticipatamente per i chiarimenti!
;-)

 Come mai invece data.DAY_OF_WEEK non dà problemi? In fondo sono entrambi
Perche' data.DAY_OF_WEEK non la utilizzi come valore di switch (che deve 
essere una costante, come ti dice, appunto, il compilatore). 
Visto che la tua variabile data non e' costante, il compilatore da' 
errore (mentre non lo da' se usi Calendar.MONDAY, per ovvi motivi). A me 
cmq sembra piu' corretto utilizzare la classe per referenziare i suoi gli 
attributi statici, piuttosto che un oggetto istanza della classe.
Chissa' se qualche guru potrebbe dire se effettivamente ci sono 
differenze (a parte quelle estetiche ed a parte i casi particolari tipo 
l'esempio di Elena)?
Ciao, 
Tatiana

L'errore sta, come dice giustamente Tatiana, nel fatto che il membro statico
è
Calendar.MONDAY
e non
data.MONDAY (data è un'istanza di Calendar); che è sempre lo stesso numero
intero, ma fatto discendere da una referenza a oggetto - per definizione,
questa non è costante.
Tatiana ha anche ragione a dire che la classe in genere si usa per i suoi
attributi statici. Esiste però un'eccezione: quando cioè si voglia ottenere
il calendario di una nazione che segue i calendari non gregoriani, per cui
ad esempio possono esserci differenze notevoli nel computo dei giorni, dei
mesi e via dicendo.
Quando faccio Calendar.getInstance(Locale.ITALY), infatti, ottengo un
GregorianCalendar (utilizzate toString() e lo vedrete).
Quindi sostanzialmente Calendar è utile quando voglio rendere utilizzabile
la mia applicazione in diverse nazioni.
Per il problema invece di Anna (stampare la data correttamente in italiano),
basta usare:
============================================================================
======
import java.util.*;
import java.text.*;
class DataItaliana
{
    private Date data;
    private DateFormat df;
    public DataItaliana()
    {
        data = new Date();  // data di oggi
        df = DateFormat.getDateInstance(DateFormat.FULL, Locale.ITALY);
    }
    public String toString()
    {
        return df.format(data);
    }
}
public class Calendario
{
    public static void main(String[] args)
    {
        System.out.println(new DataItaliana());
    }
}

In fondo sono entrambi campi "static int"
Sì, ma li invochi su "cose" diverse!
Potrei sbagliarmi.
Il costrutto "case" vuole come parametro una _costante_: non puoi
passargli un oggetto (anche se da questo vuoi ricavare una costante),
ma una costante static sì (purché la ricavi da una classe e non da
un'istanza).
Nel caso del data.get(..), puoi mettere qualsiasi cosa (del tipo
giusto!) perché non è richiesta una costante.
-- 
Ciao
	Fabrizio

 mesi e via dicendo.
Hai ragione: infatti intendevo dire (e/o chiedere) un'altra cosa. A 
prescindere da Calendar... 
Referenziare un attributo statico di una classe qualsiasi come 
<Classe>.<attributo> invece che <istanza>.<attributo> (quando si puo', 
ovviamente, non nel caso di Elena) puo' avere dei vantaggi, se non quelli 
estetici? Secondo me, quello sarebbe IL modo corretto, ma vorrei sentire 
il parere dei "guru".
Grazie,
Tatiana

 wrote in message
news:MPG.1537cef38c7303bb98968f@news...


 
E sono d'accordo con te, fin qui non ci piove.
Ma ci sono dei casi in cui l'istanza ce l'hai gia', per altri scopi. 
Esempio banale:
          public void keyReleased(KeyEvent ke) {
            if (ke.getKeyCode() == KeyEvent.VK_L) {
                                   ^^^^^^^^^^^^^
              ...
            }   
          }
oppure
          public void keyReleased(KeyEvent ke) {
            if (ke.getKeyCode() == ke.VK_L) {
                                   ^^^^^^^
              ...
            }   
          }
sono equivalenti nei termini di performance (lo so che "esteticamentente" 
e' piu' bella la prima variante)?
Ciao, Tatiana

 > c č proprio un oggetto, che si porta dietro tutto il suo contesto.


 e' piu' bella la prima variante)?
Sai che? Suppongo che questa domanda vada posta più che ai guru del
ng... a chi ha costruito la JVM nella quale vuoi fare andare la tua
applicazione.
Ciao,
	Stefano
----------
"X WindowSSS, teSSSoro mio... lo odieremo per SSSempre"
Bill Gollum
----------

 ----------
Complimenti per la "firma": troppo divertente e centrata (e' da un po' 
che te lo volevo dire...)
Ciao,
Tatiana 

 che te lo volevo dire...)
Ah ah :) Beh a questo punto il mio smisurato ego (si fa per dire),
stimolato da cotale complimento, mi ha spinto a fare una ulteriore
prova... Date le due classi
public class DataTest {
  public static final int MY_FINAL_VAR = 5;
  public static int MY_VAR = 10;
  public DataTest() {
  }
}
public class Test {
  public static void main(String[] args) {
   DataTest t = new DataTest();
   System.out.println(t.MY_FINAL_VAR);
   System.out.println(t.MY_VAR);
   System.out.println(DataTest.MY_FINAL_VAR);
   System.out.println(DataTest.MY_VAR);
  }
}
debitamente compilate, con javap -c Test >Test.bytecode ho ottenuto
public class Test extends java.lang.Object {
    public Test();
    public static void main(java.lang.String[]);
}
Method Test()
   0 aload_0
   1 invokespecial #1 <Method java.lang.Object()>
   4 return
Method void main(java.lang.String[])
   0 new #2 <Class DataTest>
   3 dup
   4 invokespecial #3 <Method DataTest()>
   7 astore_1
   8 getstatic #4 <Field java.io.PrintStream out>
  11 iconst_5
  12 invokevirtual #5 <Method void println(int)>
  15 getstatic #4 <Field java.io.PrintStream out>
  18 getstatic #6 <Field int MY_VAR>
  21 invokevirtual #5 <Method void println(int)>
  24 getstatic #4 <Field java.io.PrintStream out>
  27 iconst_5
  28 invokevirtual #5 <Method void println(int)>
  31 getstatic #4 <Field java.io.PrintStream out>
  34 getstatic #6 <Field int MY_VAR>
  37 invokevirtual #5 <Method void println(int)>
  40 return
...ottimizzazioni del compilatore e 'estetica' a parte, direi che non
c'è differenza alcuna tra l'uno e l'altro metodo. :)
Ciao,
	Stefano


 wrote in message
news:3AD1D293...@sdb.it...


 	Stefano
Grazie!
Tatiana