Существуют ли статические языки с утиным типом?

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

Теперь вы можете встроить в компилятор больше интеллекта, чтобы он мог выводить типы, вместо того, чтобы программист явно объявлял типы; компилятор может увидеть, что MyClass реализует метод MyMethod(), и обработать этот случай соответствующим образом, без необходимости явно объявлять интерфейсы (как вы предлагаете). Такой компилятор может использовать вывод типа, например Hindley-Milner.

Конечно, некоторые статически типизированные языки, такие как Haskell, уже делают что-то похожее на то, что вы предлагаете; компилятор Haskell может определять типы (в большинстве случаев) без необходимости их явного объявления. Но очевидно, что у Java / C # такой возможности нет.

Совершенно новый ответ на этот вопрос: Go имеет именно эту функцию. Я думаю, что это действительно круто и умно (хотя мне будет интересно посмотреть, как это отразится в реальной жизни), и спасибо за то, чтобы подумать об этом.

Как описано в официальной документации (как часть Tour of Go, с примером кода):

Интерфейсы реализованы неявно

Тип реализует интерфейс, реализуя свои методы. Нет ни явного объявления намерений, ни ключевого слова «реализует».

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

Как насчет использования шаблонов в C ++?

class IMyInterface  // Inheritance from this is optional
{
public:
  virtual void MyMethod() = 0;
}

class MyClass  // Does not explicitly implement IMyInterface
{
public:
  void MyMethod()  // But contains a compatible method definition
  {
    std::cout << "Hello, world!" "\n";
  }
}

template<typename MyInterface>
void CallMyMethod(MyInterface& m)
{
  m.MyMethod();  // instantiation succeeds iff MyInterface has MyMethod
}

MyClass obj;
CallMyMethod(obj);     // Automatically generate code with MyClass as 
                       // MyInterface

На самом деле я не компилировал этот код, но считаю, что это работоспособная и довольно тривиальная C ++ - изация исходного предложенного (но неработающего) кода.

Я не вижу в этом смысла. Почему бы не указать явно, что класс реализует интерфейс и что с ним покончено? Реализация интерфейса - это то, что сообщает другим программистам, что этот класс должен вести себя так, как это определяет интерфейс. Простое наличие у метода того же имени и подписи не дает никаких гарантий того, что намерение дизайнера состояло в том, чтобы выполнить аналогичные действия с методом. Может быть, но зачем оставлять это для интерпретации (и неправильного использования)?

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

F # поддерживает статическую утиную типизацию, но с одной уловкой: вы должны использовать ограничения членов. Подробности доступны в этом запись в блоге.

Пример из цитируемого блога:

let inline speak (a: ^a) =
    let x = (^a : (member speak: unit -> string) (a))
    printfn "It said: %s" x
    let y = (^a : (member talk: unit -> string) (a))
    printfn "Then it said %s" y

type duck() =
    member x.speak() = "quack"
    member x.talk() = "quackity quack"
type dog() =
    member x.speak() = "woof"
    member x.talk() = "arrrr"

let x = new duck()
let y = new dog()
speak x
speak y

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

Наиболее популярные языки этого семейства, которые приходят на ум, включают: Haskell, Objective Caml, F # и Scala. Тот, который больше всего соответствует вашему примеру, конечно, будет Objective Caml. Вот перевод вашего примера:

open Printf

class type iMyInterface = object
  method myMethod: unit
end

class myClass = object
  method myMethod = printf "Hello, world!"
end

let callMyMethod: #iMyInterface -> unit = fun m -> m#myMethod

let myClass = new myClass

callMyMethod myClass

Примечание: некоторые использованные вами имена необходимо изменить, чтобы они соответствовали концепции OCaml о семантике регистра идентификаторов, но в остальном это довольно простой перевод.

Также стоит отметить, что ни аннотация типа в функции callMyMethod, ни определение типа класса iMyInterface не являются строго необходимыми. Objective Caml может вывести все, что есть в вашем примере, вообще без каких-либо объявлений типов.

TypeScript!

Хорошо, хорошо ... Итак, это надмножество javascript и, возможно, не является «языком», но такая статическая утиная типизация жизненно важна в TypeScript.

Boo определенно является статическим языком с утиным типом: http://boo.codehaus.org/Duck+Typing < / а>

Новые версии C ++ движутся в направлении статической утиной печати. Вы можете когда-нибудь (сегодня?) Написать что-то вроде этого:

auto plus(auto x, auto y){
    return x+y;
}

и он не сможет скомпилировать, если не будет соответствующего вызова функции для x+y.

Что касается вашей критики:

Новый «CallMyMethod» создается для каждого типа, который вы ему передаете, поэтому на самом деле это не вывод типа.

Но это вывод типа IS (можно сказать foo(bar), где foo - шаблонная функция) и имеет тот же эффект, за исключением того, что он более эффективен по времени и занимает больше места в скомпилированном коде.

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

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

В любом случае это позволяет неявно и случайно нарушить иерархию классов, что плохо для новой функции, потому что это противоречит привычкам программистов C # / Java. С шаблонами C ++ вы уже знаете, что находитесь на минном поле (и они также добавляют функции («концепции»), чтобы разрешить ограничения на параметры шаблона).

Структурные типы в Scala делают примерно следующее.

См. Статически проверенный «Утиный ввод» в Scala

Предварительная версия Visual Basic 9 поддерживала статическую утиную типизацию с использованием динамических интерфейсов, но они отказались от этой функции * для своевременной доставки.

D (http://dlang.org) - это статически скомпилированный язык, обеспечивающий утиную типизацию с помощью wrap () и unwrap ( ) (http://dlang.org/phobos-prerelease/std_typecons.html#.unwrap).

Crystal - это язык со статическим утиным типом. Пример:

def add(x, y)
  x + y
end

add(true, false)

Вызов add вызывает эту ошибку компиляции:

Error in foo.cr:6: instantiating 'add(Bool, Bool)'

add(true, false)
^~~

in foo.cr:2: undefined method '+' for Bool

  x + y
    ^

Похоже на примеси или черты характера:
http://en.wikipedia.org/wiki/Mixin
http://www.iam.unibe.ch/~scg/Archive/Papers/Scha03aTraits.pdf

В последней версии моего языка программирования Heron он поддерживает нечто подобное с помощью оператора приведения структурных подтипов под названием as . Так что вместо:

MyClass obj = new MyClass();
CallMyMethod(obj);

Вы бы написали:

MyClass obj = new MyClass();
CallMyMethod(obj as IMyInterface);

Как и в вашем примере, в этом случае MyClass не обязательно явно реализовывать IMyInterface, но если бы это было так, приведение могло произойти неявно, и оператор as можно было бы опустить.

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