«Утиная типизация» (Duck-typing) — зло или благо?

Я джва года о таком мечтал.

а си-погромисты на таком пишут с 90-х годов. ;-) а с некоторого времени — даже пользующиеся gcc (-fplan9-extensions).

становится можно делать две вещи: анонимно вкладывать одну структуру в другую и вызывать функции, принимающие указатель на структуру, передавая им указатель на «большую» структуру (проверяется при компиляции).

struct biobufhdr {...};
struct biobuf {biobufhdr; uchar b[bsize];};
int bfunc(biobufhdr *b) {...}

(это пример из стандартной библиотеки plan9, смысл в том, что если размер буфера (bsize) устраивает, можно пользоваться biobuf, а если нет — определить свою «обертку» над biobufhdr с нужным размером буфера, и, возможно, еще какими-то полями и, соответственно, новыми функциями)

мне почему-то казалось, что была отдельная статья на эту тему, но не нашел.

видимо, наиболее компактно — если читать отсюда:

http://golang.org/doc/effective_go.html#interfaces_and_types

Спасибо, почитаю с утра.

Лень писать самому

Ну, хоть покажи, где там слова «утиная типизация».

Некоторые альтернативно образованные и вывод типов называют «утиной типизацией».

Мда. Бывает.

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

кстати, всегда бесили такие аналогии

меня обычно интересует, какие у авторов были детские травмы

А можно с этого места поподробнее.

template<class InputIterator, class T>
  InputIterator find ( InputIterator first, InputIterator last, const T& value )
  {
    for ( ;first!=last; first++) if ( *first==value ) break;
    return first;
  }

И что это должно символизировать?

Утиную типизацию

Это нормально. Но надо чётко помнить что и куда ты передаёшь, без этого становится плохо через некоторое время.

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

ИМХО, для развесистого проекта лучше брать язык со статической типизацией

Так всё же: это благо или зло

зло, адъ и израилъ

Шаблоны позволяют делать утиную типизацию(проверяемую в статике):

template<typename T>
void call_f(T obj)
{
    obj.f(); // <- будет работать для всех типов, у которых есть метод f()
}

а теперь расскажите какие минусы несут шаблоны.

Долгая компиляция, разбухание объектного кода, малопонятный исходный код, километровые простыни сообщений об ошибках, etc.

Все проблемы(кроме первой) решаемы. Жаль, что концепты так и не появились. С ними все красиво, почти как в Haskell(и даже лучше).

Доков по нем не особо, в основном только официальная документация на сайте. Например: http://golang.org/doc/effective_go.html#interfaces_and_types http://golangtutorials.blogspot.com/2011/06/interfaces-in-go.html

Зачем нужен go?

Зачем нужен go?

Для разработки ПО очевидно. ИМХО, отличная замена С и С++ в прикладном программировании.

Так он не лучше же. Такое же г.

Шаблоны позволяют делать утиную типизацию(проверяемую в статике):

Это не утиная типизация.

Почему? Разница с

def call_f(obj):
    obj.f()

Template, or generic functions or methods apply the duck test in a static typing context; this brings all the advantages and disadvantages of static versus dynamic type checking in general.

Википедия катится в СГ, да.

глупо спорить по поводу названий. главное суть.

глупо спорить по поводу названий.

«Названий»?

главное суть.

Если для тебя «суть» «статического duck typing» и «динамического duck typing» одинакова или хотя бы схожа, у тебя проблема.

Так правильно, это разные вещи, но обе duck :) Есть статическая, есть динамическая.

это разные вещи, но обе duck :)

«Вовочка, ты мне сейчас всю физику к х*ям сведешь» (ц)

может с точки системного программиста это и проблема, а для меня нет :). Суть в том что объект считается подходящим не потому что имеет нужный тип, а потому что реализует нужный интерфейс. Я прав?

Суть в том что объект считается подходящим не потому что имеет нужный тип, а потому что реализует нужный интерфейс. Я прав?

Не знаю. Почему-то мне кажется, что реализация некого интерфейса как-то связана с типом объекта %)

«суть» «статического duck typing» и «динамического duck typing» одинакова

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

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

Просто скажи «нет» наркотикам.

как-то связана с типом объекта %)

Тип у объекта один, а интерфейсов много. Или множество интерфейсов это некое подобие множественного наследия? Короче, имхо, словоблудие всё это.

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

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

В таком случае тебе бы не мешало прислушаться к собственному совету.

Я давно уже не принимаю вещества. Но вокруг столько норкоманов, что это просто удивительно.

package main

import "fmt"

type Quacker interface {
    Quack()
}

type Human struct{}
type Duck struct{}

func (h Human) Quack() {
    fmt.Println("Fuck you")
}

func (d Duck) Quack() {
    fmt.Println("Quack")
}

func main() {
    var q Quacker
    q = Human{}
    q.Quack()
    q = Duck{}
    q.Quack()
}

Утиная типизация рулёз.

Да, «рулез», только одно но — определять Quack для Human на «всякий пожарный» — не глупо ли это? (да, и можно ли предусмотреть _всё_: можно еще добавить Woof для «защиты» от собаки и т.п.)

определять Quack для Human на «всякий пожарный»

А какой в этом смысл? Наоброт надо определять только там где нужно, никаких «пожарных».

Если не определять, то это вызовет ошибку компиляции.

Я к тому, что обе подходят под: When I see a bird that walks like a duck and swims like a duck and quacks like a duck, I call that bird a duck

Ну, я не знаком с языком, что приведен в качестве примера — ориентировался на Ruby (Python).

template

Не не не, Дэвид Блейн, засунь свою магию себе обратно откуда достал.

Нет уж, кушайте. Надо было писать в теме, что речь о динамике :)

Ну то что у меня написано компилируется, но диспетчирезуется в рантайме динамически. Ближайшая альтернатива на C☦☦ — наследование класса с виртуальной функцией.

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

пичалька, можно же было всё сделать на этапе компиляции.

В данном примере да, в более сложном случае уже не особо.

А как оно в рантайме динамически диспетчеризуется?

Можно написать абстрактный класс и шаблонную реализацию wrapper'а, которая будет брать объект любого класса с соответствующим методом и сделает из него наследника абстрактного класса. Будет то же самое.

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

Насколько я понимаю, в переменной хранится пара тип/значение.

Из самого языка рефлексия тоже доступна.

http://golang.org/doc/articles/laws_of_reflection.html

А, не туда посмотрел (на с++).