[JAVA] un dubbio o mistero da sfatare

[a2000]

no, non vorrei che un uso polimorfo della testa possa avere gli stessi sterili effetti di un uso polimorfo che so' .... del culo, ecco !

[misterx]

Originariamente inviato da a2000
no, non vorrei che un uso polimorfo della testa possa avere gli stessi sterili effetti di un uso polimorfo che so' .... del culo, ecco !

sisi

[a2000]

Non ti perdere di coraggio se ti tocca lavorare molto e raccogliere poco…

[misterx]

beato te che non hai na mazza da fare

[a2000]

misterx tu sei la bocca della verità !


(ma limitati a quella. )

[misterx]

Originariamente inviato da a2000
misterx tu sei la bocca della verità !


(ma limitati a quella. )

ho capito, il siediti ce lo metti tu


basta, che ci bannano,........ ed avrebbero ragione

[misterx]

[PGI]

Originariamente inviato da misterx
int x = 6;
int y = 15;

y = (x = y * 2) + (x++);

quanto valgono secondo voi x ed y dopo gli assegnamenti e perchè assumono tali valori ?

x = 31
y = 60

Vai a pigliare certe gatte da pelare...

Ecco perchè Y non è 61 o 62.

Di fronte ad un'operazione matematica la jvm riserva un pezzettino di memoria (detta pila degli operandi) per infilarci temporaneamente i valori estratti dalle variabili usate. L'estrazione (bytecodeop Tload, dove T è il tipo) separa il valore nella pila degli operandi da quello contenuto nell'indirizzo associato alla variabile.

Questa "separazione" avviene nell'ordine stabilito dagli operatori che usi nel calcolo.

Ecco cosa succede nella nostra operazione:

"y =" (la parte a sinistra) è l'ultima operazione eseguita (un istore, sempre in bytecode).

La prima è la parte a sinistra dell'addizione (perchè usi un operatore + tra due elementi). A x viene assegnato il valore estratto da y (15) moltiplicato per due, x diventa 30. Il valore di x viene estratto e infilato nella pila degli operandi.

30 viene sommato al risultato dell'operazione a destra (x++). che è...30.

Perchè? Perchè l'incremento destro (x++) opera dopo che il valore è stato estratto (a differenza dell'incremento sinistro ++x): e non è una questione di priorità tra operatori (le parentesi non influenzano il risultato).

E destra pertanto la jvm estrae il valore di x (30), lo infila nella pila degli operandi, poi assegna alla variabile x il valore di x+1.

A questo punto x è già diventato "31" ma l'operazione è stata eseguita sul valore di x precedente l'incremento.

E allora Y=60 e X=31.

Usando un incremento sinistro è chiaro che risulterà Y=61 e X=31.

[PGI]

M'hai fregato un'altra volta! , ci ho messo un secolo a scrivere

[a2000]

Originariamente inviato da misterx
ho capito, il siediti ce lo metti tu
...

no, come vedo, ce lo metti sempre tu !

[misterx]

Originariamente inviato da a2000
no, come vedo, ce lo metti sempre tu !

te l'ho già detto ma non mi stufo di ripetermi.......

esci dalla torre d'avorio e collabora col resto del mondo, che è meglio..........

sei troppo orgoglioso, chi fa da se sbaglia per tre

[misterx]

Originariamente inviato da PGI
M'hai fregato un'altra volta! , ci ho messo un secolo a scrivere

scusa PGI ma sto anche affrontando quel ragazzone di a2000
c'è chi invecchiando migliora ma ad a2000, quando lo hanno imbottogliato, mica glielo hanno messo il tappo



cmq, avavo postato............

int x = 6; 
int y = 15; 

y = (x = y * 2) + (x++); 

quanto valgono secondo voi x ed y dopo gli assegnamenti e perchè assumono tali valori ? 

x = 31
y = 60

in quanto ho trovato gente che mi dice che il risultato cambia in funzione del linguaggio, priprità differenti ???

[a2000]

iuuuuuu uuuuuuuu

[PGI]

Gatta da pelare 2, la vendetta.

Il risultato di quell'espressione (e di tutte le espressioni) dipende da priorità e associatività degli operatori, oltre all'implementazione dell'incremento destro (in Java prima estrae e poi incrementa, non è detto che altri linguaggi si comportino allo stesso modo).

La priorità determina quale operatore è preso in considerazione per primo.

L'associatività (sinistra o destra) determina quale tra due operatori aventi uguale priorità verrà eseguito per primo.

Tieni conto che anche le parentesi sono un operatore (a priorità massima e associativo a sinistra in Java).

Esempio super-classico sull'associatività (lo trovi in ogni libro, è sempre lo stesso ):

y=10;
z=10;

x = y - z +10

+ e - hanno priorità uguale e associatività verso sinistra: questo significa che tra i due sarà eseguito per primo quello che si trova più a sinistra.

Quindi prima viene eseguito "y-z" (=0) poi "+10" e x diventa 10.

Se l'associatività fosse verso destra il risultato sarebbe -10.

Ora, in Java l'associatività segue le regole comuni della matematica, ma essendo una proprietà definità nella progettazione del linguaggio di programmazione niente esclude che, per qualche ragione si spera, un altro linguaggio dia agli operatori un'associatività diversa.

[misterx]

approfitto ancora un pò della tua pazienza e voglia di ripassare


classe astratta non vuol dire she sia necessariamente una superclasse vero ?

[PGI]

E' esatto. Ma se ti chiedessi perchè una classe astratta non è necessariamente una super-classe, cosa risponderesti?

Per me è importante soffermarsi a lungo su questi aspetti, perchè nei linguaggi di alto livello (Java, c++ &co.) la conoscenza di come si scrive un ciclo for o di cosa faccia il programma quando dichiari un int contano come il due di picche: qui la potenza stà nella produttività e se conosci veramente le regole che "dirigono" le relazioni tra oggetti puoi passare dall'idea all'applicazione in un tempo incredibilmente breve, altrimenti ti ritrovi a trattare gli oggetti come se fossero variabili un po' più complicate.

[misterx]

Originariamente inviato da PGI
E' esatto. Ma se ti chiedessi perchè una classe astratta non è necessariamente una super-classe, cosa risponderesti?

una domanda/risposta potrebbe essere:
perchè sento la necessità di creare classi astratte ?

e rispondendomi:
per riunire(dirigere) attraverso una superclasse (dichiarando al suo interno i metodi astratti delle sottoclassi) sottoclassi che hanno qualcosa in comune tra loro

ma perchè creare una superclasse concreta sopra ad una classe astratta?

il tempo di pensarci e torno

[PGI]

Originariamente inviato da PGI
supporto Java al binding statico e dinamico

Mi auto-cito per chiudere una "finestra lasciata aperta".

In Java esistono entrambe le forme di "binding", il "late binding" e l' "early binding".

Bella forza lo dice Eckel, penseranno molti. E' vero, ma per chi non si fidasse dell'autore, ci sono tre righe nelle specifiche del linguaggio Java (http://java.sun.com/docs/books/vmspe...doc.html#16348) in cui è confermato che di fronte al modificatore "final" (e quindi anche a "private") il riferimento al metodo viene sostituito dal contenuto del metodo, il che corrisponde appunto al modello di collegamento statico.

[PGI]

Do una risposta alla domanda che ti avevo fatto:

Astrazione (e accesso/visibilità) ed ereditarietà appartengono a due aspetti complementari della programmazione OOP.

Astrazione e visibilità (public, protected, private) definiscono gli attributi di una classe (in sintesi il "com'è fatta").

L'ereditarietà è la disciplina della relazione tra classi e comprende l'estensione (che determina le relazioni padre-figlio) e il polimorfismo (conseguenza dell'estensione).

L'ereditarietà dipende dagli attributi della classe genitrice ma i due aspetti sono concettualmente separati, dal che si capisce perchè l'uso di una "tecnica" appartenente alla definizione del modello (ad esempio proprio "abstract") non dipenda dal rapporto ereditario.

Per quanto riguarda la necessità di creare classi astratte non è una necessità, come non lo è un approccio strettamente OOP quando usi Java (se crei un'applicazione usando una sola classe per fare tutto, magari eviti pure, per quanto possibile, di usare oggetti predefiniti nelle librerie Java, beh, quell'applicazione è OOP quanto io sono un sarchiapone).

Personalmente credo a quanti scrivono che la programmazione orientata agli oggetti è sopratutto pensare alla propria applicazione come se fosse il prodotto delle relazioni tra "entità vive". Gli oggetti nascono, muoiono e interagiscono (tanto per capirci, poi la faccenda la puoi immaginare come preferisci) ma soprattutto hanno delle caratteristiche che li distinguono. Il codice sorgente di un'applicazione scritta con un approccio OOP non deve essere una serie sterile di operazioni eseguite in una sequenza più o meno dipendente dalle azioni di chi la userà: è un mondo di tanti piccoli esserini che vivono tra loro che quanto arriva l'utente devono dire "Hey ragazzi, è arrivato l'imperatore".

La cosa è più importante di quanto il mio delirio filosofico faccia supporre

Tornando alle classi astratte, l'utilità si presenta quando nella gerarchia che crei un modello puro o semipuro rappresenta meglio la realtà che stai cercando di descrivere.

Ad esempio, creando una gerarchia di oggetti che rappresentino l'abusato modello animale, la superclasse "mammifero" dovrebbe essere un modello puro o semi-puro, perchè non esiste il "mammifero" ma esisono animali che sono mammiferi (in OOP, non è coerente che "mammifero" sia istanziabile direttamente).

&Ciao.

[a2000]

Originariamente inviato da PGI
...
è un mondo di tanti piccoli esserini che vivono tra loro che quanto arriva l'utente devono dire "Hey ragazzi, è arrivato l'imperatore".

La cosa è più importante di quanto il mio delirio filosofico faccia supporre

hai ragione è terribilmente più importante.

nel mio mondo non esistono esserini e imperatori ma furie incazzate che quando vedono il presunto imperatore non dicono ma .... fanno !
e hanno tutto il mio plauso.

mi pare, e vorrei sbagliarmi, che ci sia qualcosa di "ereditariamente" servile nel mondo dell'informatica.