Java 2 SE 5: Considerazioni personali.

[mjordan]

Che c'e' di strano?
Viene richiamato il costruttore oveloaded

public Studente(int matricola){}

Non capisco cosa vuoi evidenziare.

[Angus]

Originariamente inviato da mjordan

In ogni caso, al di la della precedenza, sarebbe stato piu' giusto emettere almeno un warning, perche' l'ambiguita logica e' palese. Entrambi i metodi sovraccaricati potrebbero essere candidati possibili). In C, per esempio, il compilatore emette un warning quando fai una conversione di tipo automatica senza un casting esplicito.

E' tanto che non compilo C, ma sei sicuro che avvenga sempre? Io ricordo che accade solo se il casting implicito portasse a possibile perdita di informazione. Seguendo invece il tuo ragionamento il compilatore dovrebbe emettere un warning per il seguente codice, non ambiguo a mio parere:

public static void print(int i) { System.out.println("int " + i); }
public static void print(double d) { System.out.println("double " + d); }
public static void main(String... args) { print(3); }

In generale e' considerato "male" avere regole implicite in un linguaggio.

Dipende...

In sostanza, quello che voglio dire io, e' che per me quello che era corretto in quel momento nella mia testa era il metodo scartato. Quindi io e il compilatore concettualmente la pensavavamo diversamente in quel momento.

Il compilatore non può preoccuparsi di cosa pensa il programmatore, al limite può sforzarsi di fargli scrivere del codice corretto e non ambiguo.

Comunque, ho imparato qualcosa di nuovo,
...
se n'e' andata la giornata appresso a sta cagata Quando uno e' convinto che il codice che ha scritto e' giusto purtroppo ecco i risultati...

Quando non hai dubbi è il momento di andarteli a cercare... Spesso mi ritrovo a controllare con dei semplici test se le mie verità coincidono con la realtà...

[mjordan]

Originariamente inviato da Angus

E' tanto che non compilo C, ma sei sicuro che avvenga sempre? Io ricordo che accade solo se il casting implicito portasse a possibile perdita di informazione. Seguendo invece il tuo ragionamento il compilatore dovrebbe emettere un warning per il seguente codice, non ambiguo a mio parere:

public static void print(int i) { System.out.println("int " + i); }
public static void print(double d) { System.out.println("double " + d); }
public static void main(String... args) { print(3); }

Bhe', i warning del compilatore C dipendono appunto dal compilatore e dai flag che controllano la paranoia dei warning, non c'e' un comportamento predefinito. GCC 4.0.0 rompe le balle anche quando due tipi differiscono in segno. Per quanto riguarda il mio discorso, esso si riferiva ai metodi sovraccaricati varargs. Il tuo codice in questo caso non e' ambiguo proprio perche' passare "3" come argomento e' diverso che passare "3.0", quindi l'ambiguita' non sussiste. L'ambiguita' che evidenziavo io era sul numero di parametri passato per argomento, non nella risoluzione dei tipi.

Il compilatore non può preoccuparsi di cosa pensa il programmatore, al limite può sforzarsi di fargli scrivere del codice corretto e non ambiguo.

Quindi sostituirsi al programmatore Il compilatore non e' soltanto uno strumento per generare codice. Un buon compilatore e' il primo strumento di testing. I metri di qualita' di un compilatore sono anche l'utilita' dei messaggi che e' in grado di generare. Tanto piu' e' loquace (purche' coerente) tanto piu' aiuta nella stesura del codice. L'esempio che ho dato io prima e' un codice "corretto in sintassi" ma "scorretto in logica" perche' presenta piu' di un caso valido. Siccome non mi vengono possibili circostanze in cui avere due metodi varargs sovraccaricati in quel modo possa risultare utile (e comunque realizzabili in modo diverso e sicuramente piu' chiaro), per come la penso io dovrebbe generare almeno un warning, anche in vista del fatto che il codice presentato da cisc addirittura abortisce con un errore. Le differenze sono molto sottili, ma presenti. Se stavamo parlando di C o C++ probabilmente la questione non sarebbe sorta. Ma Java nelle sue specifiche sottolinea la parola "robusto" nella descrizione del linguaggio. Chiaramente un programmatore non puo' essere sempre in grado di garantire la robustezza di quello che scrive e qui il compilatore e' un valido aiuto.

Voglio provare a sollevare la questione sul JCP, voglio vedere cosa mi dicono

[Angus]

Originariamente inviato da mjordan

GCC 4.0.0 rompe le balle anche quando due tipi differiscono in segno.

intendi signed/unsigned? Non ci sarebbe possibile perdita di informazione?

Per quanto riguarda il mio discorso, esso si riferiva ai metodi sovraccaricati varargs. Il tuo codice in questo caso non e' ambiguo proprio perche' passare "3" come argomento e' diverso che passare "3.0", quindi l'ambiguita' non sussiste. L'ambiguita' che evidenziavo io era sul numero di parametri passato per argomento, non nella risoluzione dei tipi.

Intendevo fare un paragone proprio a livello logico ma non ho reso l'idea.
Ti sei chiesto cosa succede se dichiari un metodo m(int... interi) e lo invochi come m()? Succede che il compilatore effettua la chiamata come m(x) dove x è un'istanza di int[], e non NULL come si potrebbe anche pensare. Quindi nel caso da te citato, è logico che a fronte della chiamata m(1) il compilatore scelga di invocare il metodo m(int i) piuttosto che m(int i, int... x) che comporterebbe la creazione ad hoc di un'istanza di int[].

Il compilatore non e' soltanto uno strumento per generare codice. Un buon compilatore e' il primo strumento di testing. I metri di qualita' di un compilatore sono anche l'utilita' dei messaggi che e' in grado di generare. Tanto piu' e' loquace (purche' coerente) tanto piu' aiuta nella stesura del codice.

Sono d'accordo, anche se ci sono altre correnti di pensiero che preferiscono affibbiare l'onere della correttezza logica del codice ad appositi framework di test, rendendo più 'accomodante' il compilatore...

L'esempio che ho dato io prima e' un codice "corretto in sintassi" ma "scorretto in logica" perche' presenta piu' di un caso valido.

E' qui che non ti capisco... Per me è alla stessa strega del casting implicito se necessario e sicuro. Con la tua logica anche m(int i) e m(double d) potrebbero rendere ambigua la chiamata m(3).

per come la penso io dovrebbe generare almeno un warning, anche in vista del fatto che il codice presentato da cisc addirittura abortisce con un errore.

Il codice di cisc da un errore in fase di compilazione, non di esecuzione. Quindi direi che il compilatore ti avvisa eccome!

Voglio provare a sollevare la questione sul JCP, voglio vedere cosa mi dicono

Facci sapere