La deprecazione è considerata dannosa? [chiuso]

Motivi della deprecazione (in generale):

• Indica chiaramente alle persone che qualcosa è una cattiva pratica (e si spera suggerisca un'alternativa).
• Il periodo di deprecazione offre alle persone la possibilità di cambiare il codice prima che il compilatore lo rimuova completamente.

Inoltre non sono d'accordo sull'ultimo punto. I compilatori non ignorano il comitato e alla fine rimuovono cose deprecate (ad esempio >?= e <?= in GCC - sono state deprecate e poi rimosse *).

Penso che il punto importante sia: alcune cose dovrebbero essere rimosse, per vari motivi, e penso che la deprecazione sia l'unico modo per farlo. In questo caso specifico, auto_ptr deve essere rimosso poiché è stato sostituito da unique_ptr . Cambiare è abbastanza facile, e le persone avranno tutto il tempo per farlo.

(*) Sì, so che sono estensioni e non standard, ma il punto è che i produttori di compilatori alla fine rimuovono le cose una volta che entrano nella deprecazione, se il codice si basa ancora su di loro o meno.

Qualunque API sufficientemente complicata avrà probabilmente difetti che non vengono scoperti fino a dopo che sono stati utilizzati per un po 'di tempo. Le nostre opzioni:

• Lascia le cose come sono. Ciò significa che l'API continuerà a raccogliere sempre più cruft mentre si evolve nel tempo. Anche se vengono aggiunte versioni nuove e migliorate, anche quelle vecchie devono essere mantenute.
• Rimuovilo senza preavviso. È probabile che si rompa molto codice.
• Deprecati e rimuovili in una versione successiva. Questo dà il tempo di correggere il codice esistente, assicurando al contempo che la quantità di cruft rimanga limitata.

La deprecazione è la più sicura di queste alternative.

Nah. La deprecazione può essere davvero una buona cosa. Impedisce alle tecnologie di rimanere bloccati con il vecchio bagaglio inutile.

Solo nell'arena C ++, ricordo la "caratteristica" di Microsoft di non supportare correttamente la dichiarazione delle variabili all'interno di una dichiarazione for. Ciò è andato avanti per circa un decennio e ha reso molto codice non portatile. Questa è una "caratteristica" che mi fa piacere che sia deprecato.

Più in generale, Apple ha avuto l'abitudine fin dagli anni '80 di contrassegnare le vecchie e grezze API come "deprecate" per 5-7 anni prima di strattonarle. Stavo solo parlando con un ingegnere Apple al WWDC sulla deprecazione di alcune delle antiche API QuickTime C, ed è stato davvero un piacere sapere che lo stavano facendo, perché il continuo supporto per un modello sviluppato intorno al 1990 stava ostruendo completamente ciò che ci si aspetterebbe di essere in grado fare su moderne CPU multicore a 64 bit.

In pratica, gli scrittori di compilatori impiegheranno molto tempo per scaricare auto_ptr e probabilmente supporteranno alcune modalità di retrocompatibilità per un decennio o due, ma è una buona cosa imo.

if we really want to deprecate things, I nominate printf()

printf è una funzione utile. Permette di formattare le cose in modo più breve degli iostreams. Ed è una funzione C. La ragione per cui C ++ esiste e viene usata è perché è compatibile con C. Quindi deprecating printf sembra meno utile.

So, anyone else up for an anti-deprecation crusade?

Il comitato è a conoscenza di alcuni dei problemi dell'attuale presunto significato di deprecazione. Vedi il significato della deprecazione .

Lingue e API devono andare avanti. Anche se ci potrebbe essere una tonnellata di codice a seconda di alcune vecchie funzionalità, potrebbe esserci un modo nuovo e migliore per fare qualcosa e il costo di supportare la vecchia funzionalità è davvero troppo.

La deprecazione indica anche che in futuro la funzionalità verrà rimossa. Questo dà agli sviluppatori il tempo di aggiornare il loro codice se stanno tenendo il passo con la nuova API. Questo è molto meglio dell'alternativa: rimozione definitiva. Ricorda che l'ammortamento è un avvertimento, non un errore.

E se questo è un vecchio programma che non vuoi aggiornare, niente ti impedisce di usare la vecchia API (o in questo caso il compilatore).

Allo stato attuale, la deprecazione ha almeno due significati.

• Sarà rimosso in una versione futura
• Abbiamo creato alternative migliori e ora la funzione è ridondante (ma non del tutto inutile). I nuovi arrivati farebbero meglio a saltare questo mentre imparano la lingua; tuttavia, non verrà rimosso in qualsiasi momento presto.

Penso che la static cada nella seconda categoria, ma solo il tempo dirà se auto_ptr merita davvero di essere rimosso o se è meglio tenerlo nella lingua.

La deprecazione non è dannosa se lo spostamento verso un'alternativa può essere fatto in 1 giorno lavorativo: es. semplice ricerca / sostituzione della vecchia funzione con la nuova, o un livello di compatibilità è facile da configurare.

Se hai bisogno di riscrivere grandi parti del software a causa della deprecazione, allora è dannoso.

Un buon esempio potrebbe essere probabilmente l'API mysql di PHP, in pratica è sufficiente sostituire tutto mysql_ * con mysqli_ * e fornire un id di collegamento per loro ed è fatto.

Un cattivo esempio è la deprecazione e la rimozione di glBegin, glEnd e tutto il materiale di calcolo a matrice da OpenGL, se vuoi che il tuo codice funzioni su OpenGL3 o superiore, dovrai riscrivere l'intero codice di rendering per utilizzare i buffer dei vertici.

Penso che sia un buon modo per far sapere alla gente che esiste un modo migliore. Preferisco di gran lunga una bella deprecazione piuttosto che una funzione che sta scomparendo.