Думки про псевдоніми / синоніми типу?

Я спробую зробити все можливе, щоб вирішити це питання таким чином, щоб це не призвело до мовної війни чи списку, тому що я думаю, що на це питання може бути хороша технічна відповідь.

Різні мови в різному ступені підтримують псевдоніми типів. C # дозволяє псевдоніми типів оголошувати на початку кожного файлу коду, і вони дійсні лише у всьому цьому файлі. Такі мови, як ML / Haskell, використовують псевдоніми типу, ймовірно, настільки ж, наскільки вони використовують визначення типів. C / C ++ є на зразок Дикого Заходу, typedefі #defineчасто використовується, здавалося б, взаємозамінно для псевдонімів.

Зовнішні типи псевдоніму не викликають занадто великих суперечок:

• Це дозволяє зручно визначати складові типи, які природно описані мовою, наприклад, type Coordinate = float * floatабо type String = [Char].
• Довгі імена можуть бути скорочені: using DSBA = System.Diagnostics.DebuggerStepBoundaryAttribute.
• У таких мовах, як ML або Haskell, де параметри функцій часто не мають імен, псевдоніми типів надають вигляд самодокументації.

Мінус - дещо складніший: псевдоніми можуть поширюватися, утрудняючи читання та розуміння коду чи вивчення платформи. API Win32 - хороший приклад, DWORD = intі його, HINSTANCE = HANDLE = void*і його, LPHANDLE = HANDLE FAR*і таке. У всіх цих випадках навряд чи має сенс розрізняти HANDLE та недійсний покажчик або DWORD та ціле число тощо.

Якщо відмовитись від філософської дискусії про те, чи повинен король дати повну свободу підданим, і нехай вони будуть відповідальні за себе чи чи слід втручатися у всі їх сумнівні дії, чи може бути щасливий засіб, який би дозволив отримати переваги згладжування типу? пом'якшення ризику його зловживань?

Наприклад, питання довгих імен можна вирішити за допомогою хороших функцій автозаповнення. Наприклад, Visual Studio 2010 дозволить вам ввести DSBA, щоб віднести Intellisense до System.Diagnostics.DebuggerStepBoundaryAttribute. Чи можуть бути інші особливості, які б безпечніше забезпечували інші переваги типу сшивання?

На думку мені приходять дві особливості:

Переносність. У таких мовах , як C, де типи дані , як intце від платформи, псевдонім , як DWORDробить його легше переконатися , що ви дійсно використовуєте 32bit підписаного цілого всюди, коли це є вимогою для вашої програми, навіть якщо порт програма на Plattform , де intзнаходиться наприклад, 16-бітний без підпису і тому DWORDмає бути псевдонімом signed long.

Абстракція. У своїй програмі ви можете використовувати безліч цілих чисел із числами з плаваючою комою для різних цілей. Створюючи псевдоніми , як SPEED, HEIGHT, TEMPERATURE, це відносно легко змінити один з тих , хто , наприклад , від floatдо doubleі залишити іншим , як вони є.

Я погоджуюся з Андреєю, вам потрібна інкапсуляція, проте я не погоджуюся, що це потрібно дорого.

Я думаю, що середовище Happy буде типовим безпечним typedefs, ймовірно, що дозволяє явне перетворення між реальним типом і typedef, але запобігає імплікаційному перетворенню.

тобто головна проблема, яку я бачу з typedefs у багатьох мовах, - це те, що вони насправді не вводять новий тип, а просто псевдонім, хоча це корисно, це не так корисно, як новий тип, як старий тип, але з новим назва. А склад або спадщина занадто важкі, якщо ви хочете лише переконатися, що ви не змішуєте пару змінних.

Я думаю, що псевдоніми типів дають ледачому програмісту (дуже) дешеву інкапсуляцію. Тож можливо альтернативою може бути просто використання правильної (дорогої) інкапсуляції.

Існує також аргумент, що перший також набагато більш оптимізований для машини / мови, що використовується, ніж останній.