¿Pensamientos sobre alias de tipo / sinónimos?

Voy a hacer mi mejor esfuerzo para enmarcar esta pregunta de una manera que no resulte en una guerra de idiomas o una lista, porque creo que podría haber una buena respuesta técnica a esta pregunta.

Diferentes idiomas admiten alias de tipo en diversos grados. C # permite que los alias de tipo se declaren al comienzo de cada archivo de código, y solo son válidos en todo ese archivo. Los lenguajes como ML / Haskell usan alias de tipo probablemente tanto como usan las definiciones de tipo. C / C ++ son una especie de Salvaje Oeste, typedefy a #definemenudo se usan de manera intercambiable para tipos de alias.

Las ventajas del alias de tipo no invocan demasiada disputa:

• Hace que sea conveniente definir tipos compuestos que el lenguaje describe de forma natural, por ejemplo, type Coordinate = float * floato type String = [Char].
• Los nombres largos se pueden acortar: using DSBA = System.Diagnostics.DebuggerStepBoundaryAttribute.
• En lenguajes como ML o Haskell, donde los parámetros de función a menudo no tienen nombres, los alias de tipo proporcionan una apariencia de autodocumentación.

La desventaja es un poco más dudosa: los alias pueden proliferar, lo que dificulta la lectura y comprensión del código o el aprendizaje de una plataforma. La API Win32 es un buen ejemplo, con su DWORD = inty su HINSTANCE = HANDLE = void*y su LPHANDLE = HANDLE FAR*y tal. En todos estos casos, casi no tiene sentido distinguir entre un MANGO y un puntero vacío o un DWORD y un número entero, etc.

Dejando a un lado el debate filosófico de si un rey debería dar total libertad a sus súbditos y dejarlos ser responsables de sí mismos o si deberían intervenir todas sus acciones cuestionables, ¿podría haber un medio feliz que permitiera los beneficios del alias tipográfico mientras mitigar el riesgo de su abuso?

Como ejemplo, el problema de los nombres largos se puede resolver con buenas características de autocompletar. Visual Studio 2010, por ejemplo, le permitirá escribir DSBA para referir Intellisense a System.Diagnostics.DebuggerStepBoundaryAttribute. ¿Podría haber otras características que proporcionarían los otros beneficios del alias de tipo de forma más segura?

Dos características me vienen a la mente:

Portabilidad. En lenguajes como C, donde los tipos de datos intson específicos de la plataforma, un alias como DWORDhace que sea más fácil asegurarse de que realmente está utilizando un entero con signo de 32 bits en todas partes, cuando este es el requisito para su programa, incluso cuando lo transfiere a una plataforma donde intestá por ejemplo, 16 bits sin signo y, por lo tanto, DWORDdebe ser un alias para signed long.

Abstracción. En su programa, puede usar muchos números enteros y de coma flotante para diferentes propósitos. Mediante la creación de alias como SPEED, HEIGHT, TEMPERATURE, es relativamente fácil de cambiar uno de los ejemplo de floata doubley dejar a los demás tal como son.

Estoy de acuerdo con Andrea en que necesita encapsulación, sin embargo, no estoy de acuerdo con que esto deba ser costoso.

Creo que el medio Happy sería typedefs de tipo seguro, probablemente permitiendo la conversión explícita entre el tipo real y el typedef, pero evitando la conversión implícita.

es decir, el principal problema que veo con typedefs en muchos idiomas es que en realidad no introducen un nuevo tipo sino simplemente un alias, aunque esto es útil, no es tan útil como un tipo nuevo que es como el tipo antiguo pero con un nuevo nombre. Y la composición o la herencia son demasiado pesadas si solo quieres asegurarte de no mezclar un par de variables.

Creo que los alias de tipo le dan al programador perezoso (muy) una encapsulación barata. Entonces, tal vez la alternativa podría ser simplemente usar la encapsulación adecuada (costosa).

Sin embargo, también existe el argumento de que el primero también está mucho más optimizado para la máquina / lenguaje en uso que el segundo.