Pensieri su alias / sinonimi di tipo?


10

Farò del mio meglio per inquadrare questa domanda in modo da non provocare una guerra o un elenco linguistico, perché penso che potrebbe esserci una buona risposta tecnica a questa domanda.

Lingue diverse supportano alias di tipo a vari livelli. C # consente di dichiarare gli alias di tipo all'inizio di ciascun file di codice e sono validi solo in tutto il file. Lingue come ML / Haskell usano alias di tipo probabilmente tanto quanto usano definizioni di tipo. C / C ++ sono una specie di selvaggio West, typedefe #definespesso vengono usati in modo intercambiabile con i tipi di alias.

Gli aspetti positivi dell'aliasing di tipo non invocano troppe controversie:

  • Si rende conveniente definire tipi compositi descritti naturalmente dal linguaggio, ad esempio type Coordinate = float * floato type String = [Char].
  • I nomi lunghi possono essere accorciati: using DSBA = System.Diagnostics.DebuggerStepBoundaryAttribute.
  • In linguaggi come ML o Haskell, dove i parametri di funzione spesso non hanno nomi, gli alias di tipo forniscono una parvenza di autocertificazione.

L'aspetto negativo è un po 'più incerto: gli alias possono proliferare, rendendo difficile la lettura e la comprensione del codice o l'apprendimento di una piattaforma. L'API Win32 è un buon esempio, con suo DWORD = inte suo HINSTANCE = HANDLE = void*e suo LPHANDLE = HANDLE FAR*e tale. In tutti questi casi non ha senso distinguere tra una MANIGLIA e un puntatore vuoto o un DWORD e un numero intero ecc.

Mettendo da parte il dibattito filosofico sul fatto che un re dovrebbe dare completa libertà ai propri sudditi e lasciarli essere responsabili di se stessi o se dovrebbero intervenire tutte le loro azioni discutibili, potrebbe esserci un mezzo felice che consentirebbe i benefici dell'aliasing di tipo mentre mitigare il rischio del suo abuso?

Ad esempio, il problema dei nomi lunghi può essere risolto con buone funzionalità di completamento automatico. Visual Studio 2010, ad esempio, ti consentirà di digitare DSBA per riferire Intellisense a System.Diagnostics.DebuggerStepBoundaryAttribute. Potrebbero esserci altre funzionalità che offrirebbero gli altri benefici dell'aliasing di tipo in modo più sicuro?


Intellisense o no, System.Diagnostics.DebuggerStepBoundaryAttribute è molto meno leggibile nel codice rispetto al DSBA, specialmente se usato spesso.
zvrba,

@zvrba: in realtà, DebuggerStepBoundaryAttributeè molto più leggibile di DSBA. Nel primo caso, sai cosa significa. Nel secondo, non ne hai idea. Ora immagina di usare venti alias diversi come questo nel codice. Qualcuno avrebbe abbastanza coraggio per provare a leggere e comprendere il tuo codice?
Arseni Mourzenko,

Risposte:


3

Mi vengono in mente due caratteristiche:

Portabilità. In linguaggi come C, dove tipi di dati come intsono specifici della piattaforma, un alias come DWORDsemplifica assicurarti di utilizzare un intero con segno a 32 bit ovunque, quando questo è il requisito per il tuo programma, anche quando porti il ​​programma su una piattaforma dove intè ad es. 16 bit senza segno e quindi DWORDdeve essere un alias per signed long.

Astrazione. Nel tuo programma, potresti usare molti numeri interi e in virgola mobile per scopi diversi. Con la creazione di alias come SPEED, HEIGHT, TEMPERATURE, è relativamente facile cambiare uno di quelli ad esempio da floata doublee lasciare gli altri così come sono.


Questo non risponde alla domanda però ...
Rei Miyasaka,

@Rei, hai ragione sul fatto che ammoQ non ha risposto alla domanda ma l'ha davvero commentata. Tuttavia, P.SE non consente commenti formattati o lunghi ... Penso che non meriti un voto negativo: il suo commento è sull'argomento e buono.
Ando,

@Andrea non sembra essere il risultato di aver letto la domanda nella sua interezza; a parte la nota sulla portabilità (che è solo un altro elemento da mettere in lista degli aspetti positivi), è solo una riformulazione.
Rei Miyasaka,

2

Sono d'accordo con Andrea che hai bisogno di incapsulamento, tuttavia non sono d'accordo sul fatto che questo debba essere costoso.

Penso che il mezzo felice sarebbe scrivere typedef sicuri, probabilmente consentendo una conversione esplicita tra il tipo reale e il typedef, ma impedendo la conversione implicita.

cioè il problema principale che vedo con typedefs in molte lingue è che in realtà non introducono un nuovo tipo ma semplicemente un alias, mentre questo è utile, non è utile come un nuovo tipo che è come il vecchio tipo ma con un nuovo nome. E la composizione o l'eredità sono troppo pesanti se vuoi solo assicurarti di non mescolare un paio di variabili.


1
Non potrei essere più d'accordo, mi piacerebbe davvero vedere questo tipo di polimorfismo "limitato". Se type Name = String, quindi a Stringnon può essere passato a una funzione prevista a Name, ma è possibile il contrario.
Matthieu M.,

1

Penso che gli alias di tipo diano al programmatore pigro (molto) incapsulamento economico. Quindi forse l'alternativa potrebbe essere solo quella di usare l'incapsulamento corretto (costoso).

C'è anche l'argomento che il primo è anche molto più ottimizzato per la macchina / linguaggio in uso rispetto al secondo, però.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.