Myśli o aliasach / synonimach typów?

Postaram się jak najlepiej sformułować to pytanie w sposób, który nie spowoduje wojny językowej ani listy, ponieważ uważam, że na to pytanie można znaleźć dobrą, techniczną odpowiedź.

Różne języki obsługują aliasy typów w różnym stopniu. C # pozwala na deklarowanie aliasów typów na początku każdego pliku kodu i są one poprawne tylko w tym pliku. Języki takie jak ML / Haskell używają aliasów typów prawdopodobnie tak samo, jak używają definicji typów. C / C ++ są rodzajem Dzikiego Zachodu, typedefa #defineczęsto są używane pozornie zamiennie do typów aliasów.

Zalety aliasingu typu nie wywołują zbyt dużego sporu:

• Ułatwia to definiowanie typów kompozytów, które są naturalnie opisane przez język, np . type Coordinate = float * floatLub type String = [Char].
• Długie nazwy mogą być skracane: using DSBA = System.Diagnostics.DebuggerStepBoundaryAttribute.
• W językach takich jak ML lub Haskell, w których parametry funkcji często nie mają nazw, aliasy typów stanowią pozór samokontroli.

Minusem jest nieco bardziej niepewna: aliasy mogą się rozprzestrzeniać, co utrudnia czytanie i rozumienie kodu lub naukę platformy. Win32 API jest dobrym przykładem, z jego DWORD = inti jego HINSTANCE = HANDLE = void*i jego LPHANDLE = HANDLE FAR*i tak dalej. We wszystkich tych przypadkach nie ma sensu rozróżniać UCHWYTU od wskaźnika pustki lub DWORD i liczby całkowitej itp.

Odkładając na bok filozoficzną debatę na temat tego, czy król powinien dać swym poddanym całkowitą swobodę i pozwolić im ponosić odpowiedzialność za siebie, czy też powinien interweniować wszystkie ich wątpliwe działania, czy może istnieć szczęśliwy środek, który pozwoliłby czerpać korzyści z aliasu typu podczas gdy zmniejszając ryzyko jego nadużyć?

Na przykład problem długich nazw można rozwiązać za pomocą dobrych funkcji autouzupełniania. Na przykład Visual Studio 2010 pozwoli ci wpisać DSBA w celu skierowania Intellisense do System.Diagnostics.DebuggerStepBoundaryAttribute. Czy mogą istnieć inne funkcje, które zapewniłyby inne zalety bezpieczniejszego aliasingu typów?

Przychodzą mi na myśl dwie funkcje:

Ruchliwość. W językach takich jak C, gdzie typy danych intsą specyficzne dla platformy, alias taki DWORDułatwia upewnienie się, że naprawdę używasz 32-bitowej liczby całkowitej ze znakiem wszędzie, gdy jest to wymagane dla twojego programu, nawet gdy portujesz program na platformę, gdzie intjest np. 16-bitowy bez znaku i dlatego DWORDmusi być pseudonimem signed long.

Abstrakcja. W swoim programie możesz użyć wielu liczb całkowitych i zmiennoprzecinkowych do różnych celów. Poprzez tworzenie aliasów jak SPEED, HEIGHT, TEMPERATURE, jest to stosunkowo łatwe do zmiany jednego z tych, na przykład od floatcelu doublei pozostawić innym, jak są.

Zgadzam się z Andreą, że potrzebujesz enkapsulacji, jednak nie zgadzam się, że musi to być kosztowne.

Myślę, że szczęśliwy nośnik byłby bezpiecznym typem typów, prawdopodobnie umożliwiającym jawną konwersję między typem rzeczywistym a typedefem, ale zapobiegając domniemanej konwersji.

tzn. głównym problemem, jaki widzę w typedefs w wielu językach, jest to, że tak naprawdę nie wprowadzają nowego typu, ale po prostu alias, chociaż jest to przydatne, nie jest tak przydatne jak nowy typ, który jest podobny do starego typu, ale z nowym imię. A kompozycja lub dziedziczenie są zbyt ciężkie, jeśli chcesz mieć pewność, że nie pomieszasz kilku zmiennych.

Myślę, że aliasy typu dają leniwemu programistom (bardzo) tanie enkapsulację. Więc może alternatywą byłoby po prostu użycie właściwej (drogiej) enkapsulacji.

Istnieje również argument, że ten pierwszy jest również znacznie bardziej zoptymalizowany dla używanej maszyny / języka niż ten drugi.