Newsgroup: it.comp.java
Titolo: Binding di metodi

Scusate, qualche giorno fa è comparso un Thread interessante a proposito del
"binding" a runtime. Sarei grato se qualcuno potesse spiegarmi perchè la VM
quando si richiama il costruttore di una superclasse, questa non torna nei
metodi del "figlio" se i metodi "padre" hanno un accesso + restrittivo.
Mi spiego con un semplice esempio:
class padre {
padre() {
dosomething();  // Viene richiamato il metodo appartenente a Padre
}                          //  quando questi ha un accesso + restrittivo
private void dosomething() {
System.out.println("Padre");}
}
public class figlio extends padre {
private void dosomething() {
System.out.println("Figlio");  // Non viene invocato
}
public static void main(String args[]) {
new figlio();
}
Non mi è molto chiara la logica di questo comportamento, forse la VM opera
in questo modo perchè i metodi privati sono richiamabili esclusivamente
dall'interno della classe di appartenenza quindi hanno in qualche modo
priorità sui metodi della sottoclasse....
Attendo fiducioso commenti
Grazie 1000
Francesco

Costr(C1)->Costr(C).
Inventiamo un po' di terminologia: diciamo che un oggetto O ha una certa 
identita' X se X e' la sua classe, o la sua classe estende X in qualche punto 
della catena di derivazione; e diciamo che, in un certo istante, una sua 
identita' X e' *valida* solo se il costruttore di X e' stato eseguito, oppure 
e' in corso di esecuzione. 
Chiamiamo "tipo" l'insieme di identita' di un oggetto.
Nota che - differentemente da "classe" - "tipo" e' una nozione dinamica, non 
statica: volendo formalizzare e' un insieme completamente ordinato (in Java; in 
C++, e' parzialmente ordinato, per esempio).
Ad esempio un ogetto O di classe C ha tipo { C, C1, Object } e C, C1, e Object 
sono le sue identita'.
Per un oggetto costruito, ovviamente, tutte le identita' del suo tipo sono 
valide.
Ma ad ogni passo di costruzione Costr(Z) - e questo e' il punto - l'oggetto ha 
come identita' valide solo quelle che che stanno alla destra di Z nella catena 
di derivazione: ad esempio, al passo Costr(C1), le identita' valide sono C1 e 
Object.
Come regola generale, un oggetto puo' invocare *solo metodi delle sue identita' 
valide*. Inoltre, deve applicare le regole di protezione per l'identita' valida 
piu' a sinistra nella catena di derivazione (btw, "binding dinamico" indica 
proprio che, in caso lo stesso metodo appaia in piu' tipi, viene invocato 
quello del tipo piu' a sinistra nella catena di derivazione; eccetera).
Quindi, in un passo di costruzione Costr(Z) (per dire, Costr(C1)) un oggetto 
puo' invocare solo i metodi delle sue identita' valide (Object e C1) - e quindi 
non "vede" quelli delle altre identita' (C). Inoltre, se un certo metodo e' 
dichiarato "private" e' visibile solo dal passo di costruzione della classe che 
lo dichiara. Per le altre identita', il metodo non esiste. Formalmente 'sto 
ambaradan si puo' chiamare "spazio dei nomi" per un certo oggetto in un certo 
passo di costruzione - e tale spazio *cambia* ad ogni passo (mentre dopo la 
costruzione e' fisso).
Quindi in Costr(C1) *non* verra' mai chiamato un metodo di C; e - se Object ha 
metodi privati, C1 non li vede - quindi puo' avere metodi con la stessa 
signature, e saranno considerati solo quelli: tecnicamente non e' nemmeno un 
override.
Nel tuo codice, lo spazio dei nomi del costruttore di "padre" e' fatto da:
 
 - i metodi public, protected di Object
 - i metodi private, protected e public di "padre"
o, in altre parole, durante l'esecuzione del costruttore di "padre", "figlio" 
non e' un'identita' valida dell'oggetto figlio in costruzione.
Quindi invocare dosomething nel costruttore di "padre" portera' sempre 
all'esecuzione del metodo privato di "padre". Non cosi' in un metodo 
"normale", dove *tutte* le identita' sono valide, e lo spazio dei nomi di 
"figlio" e' fatto dai metodi public e protected di "padre" e dai metodi public, 
protected e private di "figlio", e le ambiguita' si risolvono con la regola 
"vince l'identita' piu' a sinistra nella catena di derivazione".
-- 
God is Real, unless declared Integer.
ObjectZone - 
http://space.tin.it/computer/csadun/

 [snip] un sacco di roba tecnica
Oserei dire che una spiegazione più chiara di questa sarebbe difficile trovarla da
qualche altra parte! Bravo Cristiano!
Ciao,
 Stefano
----------
"X WindowSSS, teSSSoro mio... lo odieremo per SSSempre"
Bill Gollum
----------