Cosa rende l'operatore di Scala sovraccarico "buono", ma "cattivo" di C ++?

Il sovraccarico dell'operatore in C ++ è considerato da molti come A Bad Thing (tm) e un errore da non ripetere nei linguaggi più recenti. Certamente, è stata una caratteristica specificamente abbandonata durante la progettazione di Java.

Ora che ho iniziato a leggere su Scala, ho scoperto che ha quello che assomiglia molto al sovraccarico dell'operatore (anche se tecnicamente non ha un sovraccarico dell'operatore perché non ha operatori, solo funzioni). Tuttavia, non sembrerebbe essere qualitativamente diverso dal sovraccarico dell'operatore in C ++, dove, come ricordo, gli operatori sono definiti come funzioni speciali.

Quindi la mia domanda è: cosa rende l'idea di definire "+" in Scala un'idea migliore di quella in C ++?

C ++ eredita i veri operatori blu da C. Con questo intendo che il "+" in 6 + 4 è molto speciale. Ad esempio, non puoi ottenere un puntatore a quella + funzione.

Scala invece non ha operatori in quel modo. Ha solo una grande flessibilità nella definizione dei nomi dei metodi più un po 'di precedenza incorporata per i simboli non di parole. Quindi tecnicamente Scala non ha sovraccarico dell'operatore.

Qualunque cosa tu voglia chiamarlo, il sovraccarico dell'operatore non è intrinsecamente negativo, anche in C ++. Il problema è quando i cattivi programmatori lo abusano. Ma francamente, sono dell'opinione che togliere la capacità dei programmatori di abusare del sovraccarico dell'operatore non metta una goccia nel secchio di sistemare tutto ciò che i programmatori possono abusare. La vera risposta è il mentoring. http://james-iry.blogspot.com/2009/03/operator-overloading-ad-absurdum.html

Tuttavia, ci sono differenze tra il sovraccarico dell'operatore di C ++ e la flessibile denominazione del metodo di Scala che, IMHO, rende Scala meno abusabile e più abusabile.

In C ++ l'unico modo per ottenere la notazione in-fix è usare gli operatori. Altrimenti è necessario utilizzare object.message (argomento) o pointer-> messsage (argomento) o funzione (argomento1, argomento2). Quindi, se vuoi un certo stile DSLish nel tuo codice, allora c'è la pressione di usare gli operatori.

In Scala è possibile ottenere notazioni infissi con qualsiasi messaggio inviato. "argomento messaggio oggetto" è perfettamente ok, il che significa che non è necessario utilizzare simboli non di parole solo per ottenere la notazione infix.

Il sovraccarico dell'operatore C ++ è limitato essenzialmente agli operatori C. In combinazione con la limitazione che solo gli operatori possono essere utilizzati, infissi che fanno pressione sulle persone per provare a mappare una vasta gamma di concetti non correlati su relativamente pochi simboli come "+" e ">>"

Scala consente una vasta gamma di simboli non di parole validi come nomi di metodi. Ad esempio, ho un DSL Prolog-ish incorporato in cui è possibile scrivere

female('jane)!         // jane is female
parent('jane,'john)!   // jane is john's parent
parent('jane, 'wendy)! // jane is wendy's parent

mother('Mother, 'Child) :- parent('Mother, 'Child) & female('Mother) //'// a mother of a child is the child's parent and is female

mother('X, 'john)?  // find john's mother
mother('jane, 'X)?  // find's all of jane's children

I simboli: -,!,? E & sono definiti come metodi ordinari. Solo in C ++ e sarebbe valido, quindi un tentativo di mappare questo DSL in C ++ richiederebbe alcuni simboli che già evocano concetti molto diversi.

Naturalmente, questo apre anche Scala a un altro tipo di abuso. In Scala puoi nominare un metodo $! & ^% Se vuoi.

Per altre lingue che, come Scala, sono flessibili nell'uso della funzione non-parola e dei nomi dei metodi, vedere Smalltalk dove, come Scala, ogni "operatore" è solo un altro metodo e Haskell che consente al programmatore di definire la precedenza e la fissità di nomi flessibili funzioni.

Il sovraccarico dell'operatore in C ++ è considerato da molti come una cosa negativa (tm)

Solo dagli ignoranti. È assolutamente necessario in un linguaggio come il C ++ ed è evidente che altri linguaggi che hanno iniziato ad assumere una visione "purista", l'hanno aggiunto una volta che i loro progettisti hanno scoperto quanto sia necessario.

Il sovraccarico dell'operatore non è mai stato universalmente considerato una cattiva idea in C ++ - solo l'abuso del sovraccarico dell'operatore è stato ritenuto una cattiva idea. Non è davvero necessario il sovraccarico dell'operatore in una lingua poiché possono essere simulati con chiamate di funzioni più dettagliate comunque. Evitare il sovraccarico degli operatori in Java ha reso l'implementazione e le specifiche di Java un po 'più semplici e ha costretto i programmatori a non abusare degli operatori. C'è stato qualche dibattito nella comunità Java sull'introduzione del sovraccarico degli operatori.

I vantaggi e gli svantaggi del sovraccarico dell'operatore in Scala sono gli stessi del C ++ - è possibile scrivere codice più naturale se si utilizza il sovraccarico dell'operatore in modo appropriato - e un codice più criptico e offuscato se non lo si fa.

Cordiali saluti: Gli operatori non sono definiti come funzioni speciali in C ++, si comportano proprio come qualsiasi altra funzione - anche se ci sono alcune differenze nella ricerca dei nomi, se devono essere funzioni membro e il fatto che possono essere chiamati in due modi: 1 ) sintassi operatore e 2) sintassi operatore-funzione-ID.

Questo articolo - " L'eredità positiva di C ++ e Java " - risponde direttamente alla tua domanda.

"Il C ++ ha sia allocazione di stack che allocazione di heap e devi sovraccaricare i tuoi operatori per gestire tutte le situazioni e non causare perdite di memoria. Difficile in effetti. Java, tuttavia, ha un singolo meccanismo di allocazione dello storage e un garbage collector, che rende banale il sovraccarico degli operatori". ..

Java per errore (secondo l'autore) ha omesso il sovraccarico dell'operatore perché era complicato in C ++, ma ha dimenticato il perché (o non si è reso conto che non si applicava a Java).

Per fortuna, linguaggi di livello superiore come Scala offrono agli sviluppatori opzioni, pur continuando a funzionare sulla stessa JVM.

Non c'è nulla di sbagliato nel sovraccarico dell'operatore. In effetti, c'è qualcosa di sbagliato nel non avere un sovraccarico dell'operatore per i tipi numerici. (Dai un'occhiata ad alcuni codici Java che usano BigInteger e BigDecimal.)

C ++ ha una tradizione di abuso della funzionalità, però. Un esempio spesso citato è che gli operatori bitshift sono sovraccarichi per eseguire l'I / O.

In generale non è una brutta cosa.
Nuove lingue come C # hanno anche un sovraccarico dell'operatore.

È l'abuso del sovraccarico dell'operatore che è una cosa negativa.

Ma ci sono anche problemi con il sovraccarico dell'operatore come definito in C ++. Poiché gli operatori sovraccarichi sono solo zucchero sintattico per le chiamate di metodo, si comportano proprio come il metodo. D'altra parte i normali operatori integrati non si comportano come i metodi. Queste incoerenze possono causare problemi.

Fuori dalla cima dei miei operatori ||e &&.
Le versioni integrate di questi sono operatori di scelta rapida. Questo non è vero per le versioni sovraccariche e ha causato alcuni problemi.

Il fatto che + - * / restituiscano tutti lo stesso tipo su cui operano (dopo la promozione dell'operatore)
Le versioni sovraccaricate possono restituire qualsiasi cosa (è qui che si verifica l'abuso, se i tuoi operatori iniziano a restituire un tipo di arbitro che l'utente non si aspettava le cose vanno giù per la collina).

Il sovraccarico dell'operatore non è qualcosa di cui "hai bisogno" molto spesso, ma quando usi Java, se colpisci un punto in cui ne hai davvero bisogno, ti farà venire voglia di strapparti le unghie solo così hai una scusa per smettere di scrivere .

Quel codice che hai appena trovato trabocca a lungo? Sì, dovrai riscrivere l'intero lotto per farlo funzionare con BigInteger. Non c'è niente di più frustrante che dover reinventare la ruota solo per cambiare il tipo di una variabile.

Guy Steele ha sostenuto che il sovraccarico dell'operatore dovrebbe essere anche in Java, nel suo discorso principale "Crescere una lingua" - c'è un video e una sua trascrizione, ed è davvero un discorso fantastico. Ti chiederai di cosa sta parlando per le prime due pagine, ma se continui a leggere, vedrai il punto e raggiungerai l'illuminazione. E anche il fatto stesso di poter fare un discorso del genere è sorprendente.

Allo stesso tempo, questo discorso ha ispirato molte ricerche fondamentali, tra cui probabilmente Scala - è uno di quei documenti che tutti dovrebbero leggere per lavorare sul campo.

Tornando al punto, i suoi esempi riguardano principalmente le classi numeriche (come BigInteger e alcune cose più strane), ma questo non è essenziale.

È vero, tuttavia, che l'uso improprio del sovraccarico dell'operatore può portare a risultati terribili e che persino un uso corretto può complicare le cose, se si tenta di leggere il codice senza studiare un po 'le librerie che utilizza. Ma è una buona idea? OTOH, tali librerie non dovrebbero cercare di includere un cheat sheet per gli operatori?

Credo che OGNI risposta abbia perso questo. In C ++ puoi sovraccaricare gli operatori come vuoi, ma non puoi influenzare la precedenza con cui vengono valutati. Scala non ha questo problema, IIRC.

Per quanto sia una cattiva idea, oltre alle questioni di precedenza, le persone escogitano significati davvero stupidi per gli operatori e raramente aiuta la leggibilità. Le biblioteche Scala sono particolarmente cattive per questo, simboli sciocchi che devi memorizzare ogni volta, con i manutentori delle biblioteche che attaccano le loro teste nella sabbia dicendo: "devi solo impararlo una volta". Bene, ora ho bisogno di imparare una sintassi criptica dell'autore "intelligente" * il numero di librerie che mi interessa usare. Non sarebbe così male se esistesse una convenzione di SEMPRE che fornisce una versione alfabetica degli operatori.

Il sovraccarico dell'operatore non era un'invenzione del C ++: proveniva dall'Algol IIRC e persino Gosling non sostiene che sia una cattiva idea in generale.

L'unica cosa conosciuta in C ++ è la mancanza della possibilità di sovraccaricare [] = come operatore separato. Questo potrebbe essere difficile da implementare in un compilatore C ++ per quello che probabilmente non è una ragione ovvia ma ne vale la pena.

Come hanno sottolineato le altre risposte; il sovraccarico dell'operatore non è necessariamente negativo. Cosa c'è di male quando viene utilizzato in modi che rendono ovvio il codice risultante. Generalmente quando li usi devi farli fare la cosa meno sorprendente (avere l'operatore + do divisione causerebbe problemi per l'uso di una classe razionale) o come dice Scott Meyers:

I clienti sanno già come si comportano tipi come int, quindi dovresti cercare di far sì che i tuoi tipi si comportino allo stesso modo ogni volta che è ragionevole ... In caso di dubbio, fai come fanno gli ints . (Da Effective C ++ 3rd Edition item 18)

Ora alcune persone hanno portato il sovraccarico dell'operatore all'estremo con cose come boost :: spirit . A questo livello non hai idea di come sia implementato, ma crea una sintassi interessante per ottenere ciò che desideri. Non sono sicuro che sia positivo o negativo. Sembra carino, ma non l'ho usato.

Non ho mai visto un articolo in cui si afferma che il sovraccarico dell'operatore del C ++ è negativo.

Gli operatori definibili dall'utente consentono un livello più semplice di espressività e usabilità per gli utenti della lingua.

Tuttavia, non sembrerebbe essere qualitativamente diverso dal sovraccarico dell'operatore in C ++, dove, come ricordo, gli operatori sono definiti come funzioni speciali.

AFAIK, Non c'è nulla di speciale nelle funzioni dell'operatore rispetto alle funzioni "normali" dei membri. Ovviamente hai solo un certo set di operatori che puoi sovraccaricare, ma ciò non li rende molto speciali.