Шаблоны C ++ и D - прекрасный пример нединамической утиной печати. Это определенно:

типизация, при которой текущий набор методов и свойств объекта определяет допустимую семантику, а не его наследование от определенного класса или реализации определенного интерфейса.

Вы не указываете явно интерфейс, от которого ваш тип должен наследовать для создания экземпляра шаблона. Ему просто нужно иметь все функции, которые используются внутри определения шаблона. Однако все решается во время компиляции и компилируется до необработанных, непостижимых шестнадцатеричных чисел. Я называю это «утиной типизацией во время компиляции». Я написал целые библиотеки с таким мышлением, что неявное создание экземпляров шаблона - это утиная типизация во время компиляции, и считаю, что это одна из самых недооцененных функций.

Система структурного типа

Система структурных типов сравнивает один полный тип с другим целым типом, чтобы определить, совместимы ли они. Чтобы два типа A и B были совместимы, A и B должны иметь одинаковую структуру, то есть все методы на A и B должны иметь одинаковую сигнатуру.

Утка Печатает

Утиная печать рассматривает два типа как эквивалентные для текущей задачи, если они оба могут справиться с этой задачей. Чтобы два типа A и B были эквивалентны фрагменту кода, который хочет записать в файл, A и B оба должны реализовывать метод записи.

Резюме

Системы структурных типов сравнивают каждую сигнатуру метода (всю структуру). Утиная печать сравнивает методы, относящиеся к конкретной задаче (структура, относящаяся к задаче).

Утиный ввод означает Если он подходит, все в порядке

Это относится как к динамически типизированным

def foo obj
    obj.quak()
end

или статически типизированные, скомпилированные языки

template <typename T>
void foo(T& obj) {
    obj.quak();
}

Дело в том, что в обоих примерах не было никакой информации о приведенном типе. Просто при использовании (во время выполнения или во время компиляции!) Типы проверяются, и, если все требования выполнены, код работает. Значения не имеют явного типа в момент объявления.

Структурная типизация, как обычно, полагается на явную типизацию ваших значений. Разница лишь в том, что конкретный тип идентифицируется не по наследованию, а по его структуре.

Структурно типизированный код (в стиле Scala) для приведенного выше примера будет выглядеть так:

def foo(obj : { def quak() : Unit }) {
    obj.quak()
}

Не путайте это с тем фактом, что некоторые языки со структурной типизацией, такие как OCaml, сочетают это с выводом типов, чтобы не дать нам явно определить типы.

Я не уверен, действительно ли он отвечает на ваш вопрос, но ...

Шаблонный код C ++ очень похож на утиную типизацию, но является статическим, структурным во время компиляции.

template<typename T>
struct Test
{
    void op(T& t)
    {
        t.set(t.get() + t.alpha() - t.omega(t, t.inverse()));
    }
};

Насколько я понимаю, структурная типизация используется модулями вывода типов и т. П. Для определения информации о типе (подумайте о Haskell или OCaml), в то время как утиная типизация не заботится о «типах» как таковых, просто эта вещь может обрабатывать вызов определенного метода / доступ к свойствам и т. д. (подумайте о respond_to? в Ruby или о проверке возможностей в Javascript).

Всегда будут примеры из некоторых языков программирования, которые нарушают некоторые определения различных терминов. Например, ActionScript поддерживает программирование в стиле «утка» для экземпляров, которые технически не являются динамическими.

var x:Object = new SomeClass();
if ("begin" in x) {
    x.begin();
}

В этом случае мы проверили, есть ли у экземпляра объекта в "x" метод "begin" перед его вызовом вместо использования интерфейса. Это работает в ActionScript и в значительной степени похоже на утиную типизацию, хотя класс SomeClass () сам по себе не может быть динамическим.

Существуют ситуации, в которых динамическая типизация утки и аналогичный код со статической типизацией (например, C ++) ведут себя по-разному:

template <typename T>
void foo(T& obj) {
    if(obj.isAlive()) {
        obj.quak();
    }
}

В C ++ объект должен иметь методы isAlive и quak для компиляции кода; для эквивалентного кода на языках с динамической типизацией объект должен иметь метод quak только в том случае, если isAlive() возвращает значение true. Я интерпретирую это как разницу между структурой (структурная типизация) и поведением (утиная типизация).

(Однако я пришел к этой интерпретации, приняв за чистую монету утверждение Википедии о том, что «утиная типизация должна быть динамической», и попытаться придать ей смысл. Альтернативная интерпретация, согласно которой неявная структурная типизация - это утиная типизация, также последовательна.)

Я считаю «утиную типизацию» больше стилем программирования, тогда как «структурная типизация» - это особенность системы типов.

Структурная типизация означает способность системы типов выражать типы, включающие все значения, имеющие определенные структурные свойства.

Утиная типизация относится к написанию кода, который просто использует функции передаваемых значений, которые действительно необходимы для выполняемой работы, без наложения каких-либо других ограничений.

Так что я мог использовать структурные типы для кодирования в стиле «утка», формально объявив свои «утиные типы» как структурные типы. Но я мог бы также использовать структурные типы без "утиного ввода". Например, если я пишу интерфейсы для множества связанных функций / методов / процедур / предикатов / классов / чего угодно, объявляя и называя общий структурный тип, а затем использую его повсюду, весьма вероятно, что некоторые из модулей кода не нуждаются в все функции структурного типа, поэтому я без необходимости ограничил некоторые из них, чтобы они отклоняли значения, с которыми они теоретически могли бы работать правильно.

Итак, хотя я вижу, что есть точки соприкосновения, я не думаю, что утиная типизация подразумевает структурную типизацию. Я думаю о них, утиная типизация - это даже не то, что можно было бы отнести к структурной типизации, потому что это разные вещи. Думая о утиной типизации в динамических языках как о «неявных, непроверенных структурных типах», что-то упускает, ИМХО. Утиная печать - это стиль программирования, который вы решаете использовать или нет, а не просто техническая особенность языка программирования.

Например, в Python можно использовать isinstance проверки для имитации ограничений типа «класс или подкласс» в стиле объектно-ориентированного программирования. Также можно проверить определенные атрибуты и методы, подделать ограничения структурного типа (вы даже можете поместить проверки во внешнюю функцию, таким образом эффективно получив именованный структурный тип!). Я бы сказал, что ни один из этих вариантов не иллюстрирует утиную типизацию (если только структурные типы не достаточно мелкозернистые и не синхронизируются с проверяемым им кодом).