continuazione da "imparare a programmare"

[k0nt3]

Originariamente inviato da cdimauro

Il problema, quindi, era BEN POSTO, e la soluzione che ho proposto ASSOLUTAMENTE CORRETTA.

assolutamente falso. il problema era posto in maniera ambigua, come spesso accade anche nella realtà

Originariamente inviato da cdimauro

Io, da buon programmatore, mi sono attenuto strettamente e perfettamente al problema.

mi risulta difficile attenermi strettamente a qualcosa di ambiguo. comunque prevenire potenziali comportamenti non voluti è da buon programmatore

[cdimauro]

Non c'è NESSUNA ambiguità e ti stai arrampicando sugli specchi.

Non so dove e come tu abbia studiato, ma la definizione matematica di equazione di secondo grado in quella forma che ho riportato è quella corretta, e il programma che ho scritto ricava le sue soluzioni (TUTTE, visto che ci sono sempre).

Se hai una definizione diversa, sei pregato di farmela avere, altrimenti evita di rigirare la frittata perché è del tutto inutile.

[k0nt3]

Originariamente inviato da cdimauro

Non c'è NESSUNA ambiguità e ti stai arrampicando sugli specchi.

Non so dove e come tu abbia studiato, ma la definizione matematica di equazione di secondo grado in quella forma che ho riportato è quella corretta, e il programma che ho scritto ricava le sue soluzioni (TUTTE, visto che ci sono sempre).

Se hai una definizione diversa, sei pregato di farmela avere, altrimenti evita di rigirare la frittata perché è del tutto inutile.

è ambigua ad esempio perchè non ho detto che il dominio era quello dei numeri complessi e non sta scritto da nessuna parte che è sottointeso

[fek]

Originariamente inviato da k0nt3

mi risulta difficile attenermi strettamente a qualcosa di ambiguo. comunque prevenire potenziali comportamenti non voluti è da buon programmatore

No, non lo e'. Un programmatore che cerca di prevenire potenziali problemi sta sovrangegnerizzando e perdendo tempo.
Un buon programmatore risolve solo il problema che gli e' fornito e si attiene strettamente alle specifiche date. Non implementa nulla di piu'.
Il buon programmatore prende un problema ambiguo e ne ricava specifiche non ambigue sulle quali lavorare discutendole col cliente.
E poi scrive il codice piu' semplice possibile che risolve il problema.

Originariamente inviato da k0nt3

più righe ma il risultato è diverso, anche perchè imparare a programmare non è fare la gara a chi scrive meno righe.

Si', e' anche quello.

"La soluzione e' finita non quando non c'e' piu' nulla da aggiungere, ma quando non c'e' piu' nulla da togliere"

[cdimauro]

Originariamente inviato da k0nt3

è ambigua ad esempio perchè non ho detto che il dominio era quello dei numeri complessi e non sta scritto da nessuna parte che è sottointeso

Hai detto quanto bastava, e se la matematica non è un'opinione (ma a questo punto ho il non vago sospetto che per te lo sia), un'equazione di secondo grado (nella forma data) è un "oggetto" che ha delle ben precise caratteristiche che ti ho già elencato: "a" diverso da zero e ha SEMPRE DUE soluzioni. Punto.

Se ti serve il parere di un matematico non hai che da chiederlo: nel forum ce ne sono diversi e basta scomodarne gentilmente qualcuno, ma in linea teorica certe nozioni avresti dovute averle affrontate e assimilate anche tu, sia alla scuola dell'obbligo sia all'università.

Il mio codice le rispetta in pieno: non fa né più né meno di quello richiesto, e lo fa nel più semplice dei modi.

Poi se vuoi continuare a farti ragione stravolgendo le basi della matematica e dell'informatica, dimmelo chiaramente perché la chiudiamo qui: non ho intenzione di perdere altro tempo su cose così banali e che dovrebbero essere scontate.

[cdimauro]

Originariamente inviato da k0nt3

stai cercando di travisare quello che ho detto.

Nessuna travisazione: è da un pezzo che fai lascia e prendi col discorso della scelta o non scelta del linguaggio.

io ho detto che prima di imparare un linguaggio bisogna avere una conoscenza teorica del paradigma a cui il linguaggio fa riferimento.

L'argomento è stato affrontato: per chi deve iniziare a programmare sarebbe la cosa peggiore. Non si può vivere di teoria, ma serve la pratica, altrimenti per chi deve imparare diventerebbe troppo pesante nel giro di poco tempo.

Affiancare pochi, o anche uno solo, concetti di teoria alla volta immergendosi subito nella pratica e sperimentando quanto appreso è il modo migliore per impararli e fissarli in testa.

nel caso di perl non mi basta conoscere la programmazione a oggetti perchè supporta anche altri paradigmi, ma in linea di principio niente mi vieta di iniziare dal perl (a parte che devo conoscere più di un paradigma)

Gli altri paradigmi non c'entrano niente: è sufficiente focalizzarsi su quello che interessa. Perl, quindi, va benissimo.

considerare il linguaggio macchina ha poco senso perchè per prima cosa è un linguaggio di natura diversa e richiede la conoscenza dell'hardware su cui gira.
in ogni caso l'asm (non il linguaggio macchina) può essere una scelta se si è interessati a questo tipo di programmazione e si conosce l'architettura della cpu.

Per prima cosa dovresti specificare cosa intendi con "linguaggio di natura diversa", poi ti faccio notare che l'assembly è sostanzialmente la trasposizione mnemonica del linguaggio macchina, e il requisito dell'architettura da scegliere rimane ugualmente.

Adesso dovresti cortesemente spiegarmi perché l'assembly sì e il linguaggio macchina no.

un'equazione di secondo grado prevede sempre delle soluzioni complesse, ma non sempre delle soluzioni reali. visto che non era specificato era corretto anche il mio

Ti ho già risposto nell'altro messaggio. Hai torto e non puoi ridefinire il concetto di equazione di secondo grado soltanto per farti ragione.

nel senso che è utile dividere i casi a seconda del delta. serve a imparare a programmare, altrimenti l'esempio non serve a niente

Stai aggiungendo altra carne al fuoco che è del tutto inutile: un programmatore deve innanzitutto imparare a rispettare fedelmente i requisiti del problema.

In questo caso i controlli di cui parli sono inutili, perché stai aggiungendo cose non richieste, codice e possibilità di introdurre bug.

praticamente l'hanno aggiunta ieri

Non sono tanti i compilatori che sono perfettamente aderenti allo standard ANSI 99.

dove è contorto

Basta guardare la gestione dell'input (che, tra l'altro, richiede l'uso di puntatori, e che guarda caso è una delle maggiori fonti di introduzione di bug, visto che a scanf puoi passare anche della spazzatura e non batterà ciglio) e dell'output (idem come prima, e almeno qui non sei costretto a passare puntatori, ma la spazzatura puoi sempre passargliela).

e dove sta scritto che il linguaggio più adatto a imparare è quello che richiede meno righe? è un'affermazione senza senso

Anche. Non c'è solo quello. Sei tu che stai a travisare quello che ho detto.

ai posteri la dimostrazione

Per me non c'è bisogno di aspettare così tanto tempo. Dovresti aver imparato da tempo che diffusione non è sinonimo di qualità.

non mi sembra il caso di fare dell'umorismo

Non mi sembra il caso di stravolgere la matematica: la puntualizzazione che ho fatto è doverosa. Un'equazione di secondo grado AMMETTE SEMPRE DUE SOLUZIONI, quindi anche nel caso di delta pari a zero.

[k0nt3]

Originariamente inviato da cdimauro

Hai detto quanto bastava, e se la matematica non è un'opinione (ma a questo punto ho il non vago sospetto che per te lo sia), un'equazione di secondo grado (nella forma data) è un "oggetto" che ha delle ben precise caratteristiche che ti ho già elencato: "a" diverso da zero e ha SEMPRE DUE soluzioni. Punto.

no ti sbagli! ha sempre due soluzioni solo se stai considerando i numeri complessi.
per il coefficiente diverso da zero sono daccordo con te, ma allora se il programma accetta uno zero è sbagliato

Originariamente inviato da cdimauro

Se ti serve il parere di un matematico non hai che da chiederlo: nel forum ce ne sono diversi e basta scomodarne gentilmente qualcuno, ma in linea teorica certe nozioni avresti dovute averle affrontate e assimilate anche tu, sia alla scuola dell'obbligo sia all'università.

certo che li ho affrontati, non ho problemi con la matematica. il fatto che ho scritto una soluzione al posto di due coincidenti non dimostra niente, era secondario nel contesto in cui l'ho scritto

[PGI-Bis]

Originariamente inviato da cdimauro

Va bene.

Il concetto che è stato espresso è sempre lo stesso: si tratta della definizione di una mappa/dizionario.

La "comunicazione" di quel che si sta facendo, invece, avviene in forme diverse.

Qui avrei voluto rispondere ma... mi sono dimenticato cosa io dovessi dire Mi sono anche dimenticato perchè ho risposto come ho risposto la prima volta. . Bella la giovinezza, eh?

Il numero di bug per righe di codice è una metrica molto usata nella valutazione del defect ratio di un'applicazione.

Portare un esempio in cui tale misura è pari a zero nulla toglie alla realtà speriementale, con applicazioni reali, che dipingono un quadro ben diverso (che ho riportato io).

Portare quell'esempio, invece, è sufficiente a falsificare la teoria secondo cui la mera lunghezza del codice causerebbe un aumento del defect rate. E, in effetti, noi dovremmo tener conto che le analisi statistiche sui bug dei programmi si misurano non semplicemente con codice "molto lungo" ma con codice "lungo e complicato".

Ti faccio anche presente che applicando lo stesso principio che hai esposto...

Non ho inteso esporre questo principio. Ho affermato che la lunghezza è di per sè irrilevante. Ciò che causa la scrittura di codice buggato deve essere cercato da qualche altra parte. Non so dove ma, se è induttivamente vero l'esempio che ho proposto, sicuramente non nella semplice quantità di codice.

Per me un concetto è la rappresentazione di qualcosa che ha determinate proprietà. Linguaggi diversi (ma anche programmi diversi) permettono di rappresentarlo utilizzando una diversa quantità di informazione.

Sempre per quanto mi riguarda, rappresentare qualcosa con meno informazioni aiuta nella comprensione del quadro generale in cui sono collocati questi concetti: faccio meno fatica a tenere traccia di ciò che sto facendo. Il tutto senza rinunciare alla chiarezza e alla leggibilità (in soldoni: roba come whitespace o brainfuck sono da scartare).

Più aumenta la lunghezza del codice, più la rappresentazione e la comprensione di un concetto tendono a disperdersi.
Nuovamente cito il caso dell'assembly: per rappresentare la stessa cosa ho bisogno di molte più istruzioni, e la comprensione di ciò che sto facendo diventa più problematica.
Viceversa, con Perl posso esprimere le stesse cose in maniera molto più compatta, ma a scapito di chiarezza e leggibilità.

Ricapitolando, per quanto mi riguarda il codice dovrebbe essere quanto più compatto, ma senza rinunciare a chiarezza e leggibilità.

Questo è il mio punto di vista. C'è qualcosa che non va in quello che ho scritto?

Un punto di vista non è mai criticabile in sè. E' come la vedi tu, se io dicessi è sbagliato tu saresti più che autorizzato a rispondermi "e tu vedila come cacchio ti pare". Si tratta semplicemente di cercare di capirlo e discuterne.

A me appaiono perfettamente leciti: anche in Java esistono delle istruzioni che NON rappresentano scambi di messaggi fra oggetti.

In SmallTalk non esistono istruzioni?

Nel senso di qualcosa che non sia un messaggio inviato ad un oggetto? No, non esistono.

Io lo trovo molto comodo, invece: mi basterebbe sostituire la funzione "built-in" print() con una mia per poter "reindirizzare" tutte le parti di codice che ne fanno uso.

A parte questo, non vedo perché sarebbe un punto a sfavore (se non per una maggiore immediatezza e semplicità della forma attuale): print diventerebbe un oggetto come un altro in Python, quindi rendendo il linguaggio più coerente da questo punto di vista.

Le interfacce non possono contenere attributi però, mentre le classi astratte sì: la differenza, quindi, c'è.

Non conosco Scala, per cui non so di cosa parli in quel contesto.

Non ho messo "totalmente" di fronte ad "astratta" per licenza poetica. Scala è un poco invidiabile mischione di caratteristiche, tutte molto belle ma che unite in una sola lingua richiedono il patentino da esorcista per poter essere gestite. E' un po' come Python ma polimorfo anzichè amorfo. Una cosa che permette di fare e che vorrei avesse avuto Java è la possibilità di creare la definizione di un oggetto anzichè la definizione di una categoria di oggetti da cui poi ricavare un'istanza. Come dire:

object Pippo {
    public String getName() { return "Pippo"; }
}
...
Pippo.getName();

Una specie di singleton (ogni oggetto è un singleton per il principio di identità).

Comunque non hai risposto sull'ereditarietà ed estensione multipla: ti piace? Non ti piace? Ed eventualmente perché.

L'estesione multipla non mi piace perchè richiede che sia introdotta una norma per stabilire cosa succeda quando due o più supertipi definiscano un medesimo comportamento. Es.:

class SuperOne {
    String getValue() { return "Hello" }
}

class SuperTwo {
    String getValue() { return "World" }
}

class Sub extends SuperOne, SuperTwo {
   //getValue() restituisce Hello o World ?
}

L'ereditarietà della sola dichiarazione non presenta lo stesso problema perchè è, appunto, mera dichiarazione di una capacità posseduta e non anche implementazione di quella capacità.

Dell'estensione (singola o multipla che sia) non apprezzo inoltre il fatto che essa costringa ad eccepire la comune regola secondo cui l'implementazione è sempre irrilevante: l'estensione è differisce dall'ereditarietà esattamente in ciò che la prima trasferisce dichiarazione e implementazione mentre la seconda trasferisce la sola dichiarazione. Se l'implementazione è sempre irrilevante perchè trasferirla? La risposta è per comodità ed è effettivamente comodo ma io non apprezzo le comodità che incrinano l'omogeneità dei principi.

Certamente, ma Python si avvicina di più al tuo ideale di prospettiva orientata agli oggetti: ti dà una maggior libertà di definire cos'è un oggetto e in che modo "risponde" a certe requisiti / caratteristiche, potendo anche cambiare "comportamento" dinamicamente.

Se ci fai caso sul linguaggio di per sé non ho avuto nulla di dire: Java lo trovo portatile ovunque, tanto quanto Python o altri.

Ma hai parlato anche di VM, e qui non ero d'accordo sulla portabilità e ti ho fatto un paio di esempi che mi sono venuti in mente. Tutto qui.

La VM è una cosa, le librerie sono un'altra. Tu hai fatto un esempio che non riguarda nè il linguaggio di programmazione Java nè la macchina virtuale: che facciamo?

Te ne sparo una sinteticamente: con Python è possibile modellare velocemente e in maniera semplice un problema, mantenendo il codice compatto, chiaro e manutenibile. Ci si focalizza sul problema. ;)

Così tanti spunti e così poco tempo per discuterli. Qui la chiave di volta "sinteticamente". Io credo che la sintesi sia una riduzione della quantità di parole necessaria per esprimere un concetto prodotta dal trasferimento di una parte delle informazioni dal discorso esplicito (dico tutto ciò che devi sapere) ad un campo implicito (presuppongo che tu sappia alcune delle cose necessarie a comprendere il concetto). E il punto è: esiste una misura di questo trasferimento? Quanto posso trasferire, quanto posso presupporre senza che ciò renda il discorso oscuro? Io credo che il codice Python presupponga troppo.

ROTFL. Mi fai morire.

Tanto le checked exception sono peggio del cancro dello scrivano, anche se non lo ammetterai mai.

Esiste un'articolata teoria dell'errore che richiede l'esistenza di due categorie di eccezioni, checked e unchecked, allo scopo di rappresentare due diverse categorie di condizioni eccezionali (per causa esterna e per causa interna). Che ti risparmio perchè son buono come il pane .

[cdimauro]

Originariamente inviato da k0nt3

per il coefficiente diverso da zero sono daccordo con te, ma allora se il programma accetta uno zero è sbagliato

Assolutamente no. Il programma ha un "contratto" ben definito: se gli viene dato in pasto un'equazione di secondo, com'è anche riportato TESTUALMENTE (vai a rileggerti la prima print, se dovesse esserti sfuggita, perché è scritto a chiare lettere), funziona perfettamente, ritornando le DUE soluzioni (anche complesse quindi).

Se gli fornisci qualcosa che NON è un'equazione di secondo grado, il suo comportamento E' INDEFINITO (nel senso che NON l'ho assolutamente definito e non m'importa).

Come non è definito neppure se al posto di un numero in virgola mobile digiti, ad esempio, "Pippo". Caso che, "stranamente", tu non hai considerato nemmeno di striscio con la tua versione C: eppure, secondo la tua logica, un controllo avrebbe dovuto esserci anche qui.

Comunque per maggiori informazioni su cosa significhi sviluppare programmi: http://it.wikipedia.org/wiki/Algoritmo di cui riporto uno spezzone:

"In informatica, con il termine algoritmo si intende un metodo per la soluzione di un problema adatto a essere implementato sotto forma di programma. Intuitivamente, un algoritmo si può definire come un procedimento che consente di ottenere un risultato atteso eseguendo, in un determinato ordine, un insieme di passi semplici corrispondenti ad azioni scelte solitamente da un insieme finito."

no ti sbagli! ha sempre due soluzioni solo se stai considerando i numeri complessi.

certo che li ho affrontati, non ho problemi con la matematica. il fatto che ho scritto una soluzione al posto di due coincidenti non dimostra niente, era secondario nel contesto in cui l'ho scritto

No, dimostra semplicemente che hai una concezione da scuola dell'obbligo di quelle cose: soltanto lì, quando si iniziano a trattare queste cose, si parla di un'equazione di secondo grado che può:
- avere due soluzioni;
- avere una soluzione;
- non avere soluzioni.

All'università, posto che il docente sappia fare bene il proprio dovere, si insegna che le soluzioni sono sempre due. Le soluzioni complesse si escludono SE E SOLO SE il codominio viene ristretto al campo dei reali (che, non essendo stato specificato, non è il caso nostro).

Vediamo se devi ancora continuare con questa storia.

[cdimauro]

Originariamente inviato da PGI-Bis

Qui avrei voluto rispondere ma... mi sono dimenticato cosa io dovessi dire Mi sono anche dimenticato perchè ho risposto come ho risposto la prima volta. . Bella la giovinezza, eh?

OK, lasciamo perdere.

Portare quell'esempio, invece, è sufficiente a falsificare la teoria secondo cui la mera lunghezza del codice causerebbe un aumento del defect rate. E, in effetti, noi dovremmo tener conto che le analisi statistiche sui bug dei programmi si misurano non semplicemente con codice "molto lungo" ma con codice "lungo e complicato".

Dove la definizione di "complicato" però latita.

Non ho inteso esporre questo principio. Ho affermato che la lunghezza è di per sè irrilevante. Ciò che causa la scrittura di codice buggato deve essere cercato da qualche altra parte. Non so dove ma, se è induttivamente vero l'esempio che ho proposto, sicuramente non nella semplice quantità di codice.

I bug originano dall'introduzione del concetto di salto condizionato, del tutto assente nell'esempio che hai esposto.

Un punto di vista non è mai criticabile in sè. E' come la vedi tu, se io dicessi è sbagliato tu saresti più che autorizzato a rispondermi "e tu vedila come cacchio ti pare". Si tratta semplicemente di cercare di capirlo e discuterne.

OK. Cosa ne pensi del mio punto di vista?

Nel senso di qualcosa che non sia un messaggio inviato ad un oggetto? No, non esistono.

L'istruzione di assegnazione come si configura? Anch'essa come "messaggio spedito"?

Non ho messo "totalmente" di fronte ad "astratta" per licenza poetica. Scala è un poco invidiabile mischione di caratteristiche, tutte molto belle ma che unite in una sola lingua richiedono il patentino da esorcista per poter essere gestite. E' un po' come Python ma polimorfo anzichè amorfo. Una cosa che permette di fare e che vorrei avesse avuto Java è la possibilità di creare la definizione di un oggetto anzichè la definizione di una categoria di oggetti da cui poi ricavare un'istanza. Come dire:

object Pippo {
    public String getName() { return "Pippo"; }
}
...
Pippo.getName();

Una specie di singleton (ogni oggetto è un singleton per il principio di identità).

Mumble. Io lo vedo come una classe che definisce un metodo di classe: faccio male o c'è qualcosa che mi sfugge?

L'estesione multipla non mi piace perchè richiede che sia introdotta una norma per stabilire cosa succeda quando due o più supertipi definiscano un medesimo comportamento. Es.:

class SuperOne {
    String getValue() { return "Hello" }
}

class SuperTwo {
    String getValue() { return "World" }
}

class Sub extends SuperOne, SuperTwo {
   //getValue() restituisce Hello o World ?
}

L'ereditarietà della sola dichiarazione non presenta lo stesso problema perchè è, appunto, mera dichiarazione di una capacità posseduta e non anche implementazione di quella capacità.

Dell'estensione (singola o multipla che sia) non apprezzo inoltre il fatto che essa costringa ad eccepire la comune regola secondo cui l'implementazione è sempre irrilevante: l'estensione è differisce dall'ereditarietà esattamente in ciò che la prima trasferisce dichiarazione e implementazione mentre la seconda trasferisce la sola dichiarazione. Se l'implementazione è sempre irrilevante perchè trasferirla? La risposta è per comodità ed è effettivamente comodo ma io non apprezzo le comodità che incrinano l'omogeneità dei principi.

Lo so, il tuo pensiero in merito l'hai esposto diverse volte, ma le eccezioni tante volte sono un'esigenza per poter lavorare più comodamente. Fra rischiare il suicidio pur di far fede sempre ai principi, e sviluppare con serenità un'applicazione, preferisco la seconda.

Tornando al discorso dell'ereditarietà multipla, se il linguaggio definisce bene il meccanismo di ricerca dei metodi e/o attributi, io non vedo particolari problemi nell'adottarla.

Quanto all'approccio delle interfacce, cosa succede se ne esistono due che dichiarano due metodi getValue e una classe prova ad estenderle entrambe? Non c'è anche qui la necessità di capire a quale ci si riferisce se nel codice è presente soltanto l'invocazione di getValue?

La VM è una cosa, le librerie sono un'altra. Tu hai fatto un esempio che non riguarda nè il linguaggio di programmazione Java nè la macchina virtuale: che facciamo?

Facciamo che mi riferivo alle librerie anziché alla VM: va bene lo stesso riguardo alla discorso sulla portabilità di Java?

Così tanti spunti e così poco tempo per discuterli. Qui la chiave di volta "sinteticamente". Io credo che la sintesi sia una riduzione della quantità di parole necessaria per esprimere un concetto prodotta dal trasferimento di una parte delle informazioni dal discorso esplicito (dico tutto ciò che devi sapere) ad un campo implicito (presuppongo che tu sappia alcune delle cose necessarie a comprendere il concetto). E il punto è: esiste una misura di questo trasferimento? Quanto posso trasferire, quanto posso presupporre senza che ciò renda il discorso oscuro? Io credo che il codice Python presupponga troppo.

ROTFL. Mi fai morire.

Meglio: prendere le cose troppo seriamente fa male.

Tornando a ciò che dicevi, dove starebbe il trasferimento di parte delle informazioni dal discorso esplicito a uno implicito? Insomma, dove trovi che, nella definizione in Python che ho fornito, siano celate implicitamente delle informazioni?

La sintesi serve principalmente a rimuovere delle informazioni ridondanti o inutili.

Esiste un'articolata teoria dell'errore che richiede l'esistenza di due categorie di eccezioni, checked e unchecked, allo scopo di rappresentare due diverse categorie di condizioni eccezionali (per causa esterna e per causa interna). Che ti risparmio perchè son buono come il pane .

Va bene. Tanto prima o poi capiterà di tornare sull'argomento.

[^TiGeRShArK^]

Originariamente inviato da PGI-Bis

Portare quell'esempio, invece, è sufficiente a falsificare la teoria secondo cui la mera lunghezza del codice causerebbe un aumento del defect rate. E, in effetti, noi dovremmo tener conto che le analisi statistiche sui bug dei programmi si misurano non semplicemente con codice "molto lungo" ma con codice "lungo e complicato".

ma anche no
il tuo codice è una mera ridondanza.
E' possibile esprimere il concetto che tu hai espresso con un semplicissimo

for (int i = 0; i < 100; i++){
   System.out.println("Hello world!");
}

E si ottiene lo stesso risultato.
Ora..
secondo te, inserendo lo snippet di codice col for e quello "unrolled" in un'applicazione reale, quale versione è più o meno soggetta ad errori?
(da notare che hai specificato 100 volte, quindi se sbagliando nel copia e incolla ne metti 99 o 101 allora stai introducendo dei bug)
Inoltre mettendo quello più lungo complichi incredibilmente la tua applicazione e per seguire il filo logico tra prima del tuo snippet e dopo dovresti fare i salti mortali, a meno ovviamente di non usare un extract method che ha esattamente la stessa funzione di ridurre la quantità di codice in quel metodo in modo da aumentarne la leggibilità e diminuire così la possibilità d'errore (credo che venga da se che un programma + leggibile sia meno soggetto ai bug).

L'estesione multipla non mi piace perchè richiede che sia introdotta una norma per stabilire cosa succeda quando due o più supertipi definiscano un medesimo comportamento.

su questo invece mi trovi pienamente d'accordo

[^TiGeRShArK^]

Originariamente inviato da cdimauro

Quanto all'approccio delle interfacce, cosa succede se ne esistono due che dichiarano due metodi getValue e una classe prova ad estenderle entrambe? Non c'è anche qui la necessità di capire a quale ci si riferisce se nel codice è presente soltanto l'invocazione di getValue?

perchè?
Nelle interfacce non definisci l'implementazione, sono solo utilizzate per definire un contratto.
Dato che la tua classe che implementa le interfacce deve rispettare il contratto basta che implementi un solo metodo che faccia quanto richiesto.
Quindi il caso di due metodi in due interfacce diverse mi ricorda tanto l'esempio di cui sopra delle due soluzioni reali e coincidenti (), in cui con una sola implementazione di metodo hai rispettato due contratti

[cdimauro]

Originariamente inviato da ^TiGeRShArK^

perchè?
Nelle interfacce non definisci l'implementazione, sono solo utilizzate per definire un contratto.
Dato che la tua classe che implementa le interfacce deve rispettare il contratto basta che implementi un solo metodo che faccia quanto richiesto.
Quindi il caso di due metodi in due interfacce diverse mi ricorda tanto l'esempio di cui sopra delle due soluzioni reali e coincidenti (), in cui con una sola implementazione di metodo hai rispettato due contratti

Mumble. Forse dovevo essere più chiaro. Se ho due interfacce che hanno responsabilità diverse ma definiscono lo stesso metodo getValue, questo dovrebbe definire un "comportamento" diverso per ognuna.

Per intenderci: una cosa è la getValue di un'interfaccia "ListCollection" e tutt'altra cosa è la getValue di una "DBField".

Se ho una sola implementazione per le due definizioni, quale dovrebbe essere il comportamento plasmato? Quella della prima? Quello della seconda? O una sorta di "combinazione"?

[^TiGeRShArK^]

Originariamente inviato da cdimauro

Mumble. Forse dovevo essere più chiaro. Se ho due interfacce che hanno responsabilità diverse ma definiscono lo stesso metodo getValue, questo dovrebbe definire un "comportamento" diverso per ognuna.

Per intenderci: una cosa è la getValue di un'interfaccia "ListCollection" e tutt'altra cosa è la getValue di una "DBField".

Se ho una sola implementazione per le due definizioni, quale dovrebbe essere il comportamento plasmato? Quella della prima? Quello della seconda? O una sorta di "combinazione"?

boh..
alla fine è una tua scelta immagino...
Probabilmente se arrivi a questa situazione comunque il tuo oggetto non rispetta il principio di separazione dei compiti (o come cavolo si chiama ) perchè effettua operazioni di due tipi di oggetti troppo diversi tra loro e che renderebbero il tuo oggetto una sottospecie di "ibrido".
Io personalmente separerei quindi il mio oggetto in due oggetti che implementano ognuno una delle due interfacce.
Questo sempre per restare nel tema che l'ereditarietà multipla comporta solo casini e dovrebbe essere applicata solo in caso un oggetto possa comportarsi effettivamente come specificato dalle varie interfacce che lo compongono.
Se ad esempio ho un oggetto Animale che è sia un uccello che un mammifero allora c'è qualcosa che non va

[cdimauro]

Le operazioni, anche se hanno lo stesso nome, sono separate ed è possibile "indirizzarle" con lo scoping.

Comunque neanch'io farei casini di questo tipo: era soltanto un dubbio esclusivamente sul piano formale che m'era sovvenuto.

Quindi la risposta è: no, si può implementare il metodo una sola volta per entrambe le interfacce.
A questo punto mi aspetto che se due interfacce definiscono lo stesso metodo, ma che tornano risultati diversi, linguaggi come Java, Delphi, ecc. sollevino un'errore in fase di compilazione.

[k0nt3]

Originariamente inviato da cdimauro

Assolutamente no. Il programma ha un "contratto" ben definito: se gli viene dato in pasto un'equazione di secondo, com'è anche riportato TESTUALMENTE (vai a rileggerti la prima print, se dovesse esserti sfuggita, perché è scritto a chiare lettere), funziona perfettamente, ritornando le DUE soluzioni (anche complesse quindi).

Se gli fornisci qualcosa che NON è un'equazione di secondo grado, il suo comportamento E' INDEFINITO (nel senso che NON l'ho assolutamente definito e non m'importa).

Come non è definito neppure se al posto di un numero in virgola mobile digiti, ad esempio, "Pippo". Caso che, "stranamente", tu non hai considerato nemmeno di striscio con la tua versione C: eppure, secondo la tua logica, un controllo avrebbe dovuto esserci anche qui.

Comunque per maggiori informazioni su cosa significhi sviluppare programmi: http://it.wikipedia.org/wiki/Algoritmo di cui riporto uno spezzone:

"In informatica, con il termine algoritmo si intende un metodo per la soluzione di un problema adatto a essere implementato sotto forma di programma. Intuitivamente, un algoritmo si può definire come un procedimento che consente di ottenere un risultato atteso eseguendo, in un determinato ordine, un insieme di passi semplici corrispondenti ad azioni scelte solitamente da un insieme finito."

e dove l'hai visto il contratto :| io ho visto solo una richiesta ambigua, per cui ho dato una risposta che può non essere di tuo gradimento, ma secondo me rispetta la richiesta

Originariamente inviato da cdimauro

No, dimostra semplicemente che hai una concezione da scuola dell'obbligo di quelle cose: soltanto lì, quando si iniziano a trattare queste cose, si parla di un'equazione di secondo grado che può:
- avere due soluzioni;
- avere una soluzione;
- non avere soluzioni.

All'università, posto che il docente sappia fare bene il proprio dovere, si insegna che le soluzioni sono sempre due. Le soluzioni complesse si escludono SE E SOLO SE il codominio viene ristretto al campo dei reali (che, non essendo stato specificato, non è il caso nostro).

Vediamo se devi ancora continuare con questa storia.

NO
le soluzioni complesse si includono SE E SOLO SE il codominio viene ESTESO ai numeri complessi.
ti faccio notare che qualunque insegnante serio di analisi specifica sempre all'inizio qual'è il dominio e il codominio, per cui se stiamo parlando di numeri reali anche all'università ti insegnano che possono non esserci soluzioni. i numeri complessi si usano soltanto quando servono, mentre nella maggiorparte dei casi si fa riferimento a reali
ora.. rispondi a questa domanda:
perchè non dovrebbe essere possibile dare in input al programma numeri complessi? non è sottointeso?

direi che è il caso di non andare oltre

[^TiGeRShArK^]

Originariamente inviato da k0nt3

NO
le soluzioni complesse si includono SE E SOLO SE il codominio viene ESTESO ai numeri complessi.
ti faccio notare che qualunque insegnante serio di analisi specifica sempre all'inizio qual'è il dominio e il codominio, per cui se stiamo parlando di numeri reali anche all'università ti insegnano che possono non esserci soluzioni. i numeri complessi si usano soltanto quando servono, mentre nella maggiorparte dei casi si fa riferimento a reali
ora.. rispondi a questa domanda:
perchè non dovrebbe essere possibile dare in input al programma numeri complessi? non è sottointeso?

direi che è il caso di non andare oltre

Originariamente inviato da wikipedia

quadratic equation is a polynomial equation of the second degree. The general form is

ax^2+bx+c=0

where a ≠ 0. (For a = 0, the equation becomes a linear equation.)

The letters a, b, and c are called coefficients: the quadratic coefficient a is the coefficient of x2, the linear coefficient b is the coefficient of x, and c is the constant coefficient, also called the free term or constant term.

Quadratic equations are called quadratic because quadratus is Latin for "square"; in the leading term the variable is squared.

A quadratic equation with real (or complex) coefficients has two (not necessarily distinct) solutions, called roots, which may be real or complex, given by the quadratic formula,

l'unica cosa che puoi dire a cesare è che non ha trattato il caso di coefficienti complessi, ma la sua soluzione si accorda perfettamente con la definizione di equazione polinomiale di secondo grado, come puoi anche vedere da quanto riportato.
La distinzione per delta > e < di 0 viene fatta solo quando gli studenti ancora non hanno appreso il concetto di numeri complessi.
Ma è solo una spiegazione per superare questa limitazione, infatti ti specificano chiaramente che nel domino dei numeri reali tale equazione non ammette soluzione per delta < 0.
Ma mica vuol dire che per delta minore di zero non la puoi risolvere....
Infatti se prendi la definizione generale (come quella riportata da wikipedia) vedi testualmente scritto che l'equazione di secondo grado ammette sempre due soluzioni.

[k0nt3]

la definizione del problema era ambigua perchè non è stato specificato il dominio di riferimento, quindi anche trovare solo le soluzioni reali (quando ci sono) era corretto.
non ho bisogno di cercare su wikipedia, sono cose che so già
lui ha aggiunto anche le soluzioni complesse solo per scrivere meno righe di codice.. nient'altro

[cdimauro]

Non c'è nemmeno bisogno che rispondo perché mi sono già espresso chiaramente e sono d'accordo con quanto ha scritto Danilo, tranne che su una cosa: non ho aggiunto niente; al contrario, semplicemente non ho tolto niente.

Per me la questione "risoluzione di un'equazione di secondo grado" finisce qui.

[fek]

Originariamente inviato da k0nt3

la definizione del problema era ambigua perchè non è stato specificato il dominio di riferimento, quindi anche trovare solo le soluzioni reali (quando ci sono) era corretto.
non ho bisogno di cercare su wikipedia, sono cose che so già
lui ha aggiunto anche le soluzioni complesse solo per scrivere meno righe di codice.. nient'altro

La definizione non era ambigua perche' in mancanza di menzione esplicita del codomonio ci si riferisce all'"oggetto matematico" che ha sempre due soluzioni complesse.

In caso di definizione ambigua del cliente, comunque, il buon programmatore implementa sempre la soluzione piu' semplice al problema, non la piu' complessa.