Pensamentos sobre aliases / sinônimos de tipo?

Vou tentar o meu melhor para enquadrar essa questão de uma maneira que não resulte em uma guerra ou lista de idiomas, porque acho que poderia haver uma resposta técnica boa para essa pergunta.

Idiomas diferentes suportam aliases de tipo em graus variados. O C # permite que aliases de tipo sejam declarados no início de cada arquivo de código e são válidos apenas por todo esse arquivo. Idiomas como ML / Haskell usam aliases de tipo provavelmente tanto quanto usam definições de tipo. C / C ++ é uma espécie de oeste selvagem, typedefe #definefrequentemente é usado de forma aparentemente intercambiável para tipos de alias.

As vantagens do alias de tipo não invocam muita disputa:

• Torna conveniente definir tipos compostos que são descritos naturalmente pelo idioma, por exemplo, type Coordinate = float * floatou type String = [Char].
• Nomes longos pode ser encurtado: using DSBA = System.Diagnostics.DebuggerStepBoundaryAttribute.
• Em idiomas como ML ou Haskell, onde os parâmetros de função geralmente não têm nomes, os aliases de tipo fornecem uma aparência de auto-documentação.

A desvantagem é um pouco mais duvidosa: os aliases podem proliferar, dificultando a leitura e a compreensão do código ou o aprendizado de uma plataforma. A API do Win32 é um bom exemplo, com its DWORD = inte its HINSTANCE = HANDLE = void*e its LPHANDLE = HANDLE FAR*e such. Em todos esses casos, dificilmente faz sentido distinguir entre um HANDLE e um ponteiro nulo ou um DWORD e um número inteiro etc.

Deixando de lado o debate filosófico sobre se um rei deveria dar total liberdade a seus súditos e deixá-los serem responsáveis ​​por si mesmos ou se deveriam ter todas as suas ações questionáveis ​​interpostas, poderia haver um meio feliz que permitisse os benefícios do alias de tipo enquanto mitigar o risco de abuso?

Como exemplo, a questão dos nomes longos pode ser resolvida por bons recursos de preenchimento automático. O Visual Studio 2010, por exemplo, permitirá que você digite DSBA para consultar o Intellisense como System.Diagnostics.DebuggerStepBoundaryAttribute. Poderia haver outros recursos que forneceriam os outros benefícios do alias de tipo com mais segurança?

Dois recursos me vêm à mente:

Portabilidade. Em linguagens como C, onde tipos de dados como intsão específicos da plataforma, um alias como DWORDfacilita garantir que você esteja realmente usando um número inteiro assinado de 32 bits em qualquer lugar, quando esse for o requisito do seu programa, mesmo quando você o portar para uma plataforma onde intestá por exemplo, 16 bits não assinados e, portanto DWORD, deve ser um alias para signed long.

Abstração. No seu programa, você pode usar muitos números inteiros e de ponto flutuante para diferentes propósitos. Com a criação de aliases como SPEED, HEIGHT, TEMPERATURE, é relativamente fácil mudar um daqueles por exemplo, de floatpara doublee deixar os outros como eles são.

Concordo com Andrea, você precisa de encapsulamento, no entanto, discordo que isso precisa ser caro.

Acho que o meio feliz seria type typedefs seguros, provavelmente permitindo a conversão explícita entre o tipo real e o typedef, mas impedindo a conversão implícita.

ou seja, o principal problema que vejo com typedefs em vários idiomas é que eles não introduzem um novo tipo, mas simplesmente um alias, enquanto isso é útil, não é tão útil quanto um novo tipo que é como o tipo antigo, mas com um novo nome. E a composição ou herança são muito pesadas se você deseja apenas garantir que não misture algumas variáveis.

Eu acho que aliases de tipo dão ao programador preguiçoso (muito) encapsulamento barato. Portanto, talvez a alternativa possa ser apenas usar o encapsulamento adequado (caro).

Há também o argumento de que o primeiro também é muito mais otimizado para a máquina / linguagem em uso do que o último.