Как работать с Ruby Duck Typing

Это не специфическая проблема Ruby, она одинакова для всех языков с динамической типизацией.

Обычно нет никаких указаний, как это задокументировать (и в большинстве случаев это невозможно). См., Например, карту в документации по ruby.

map { |item| block } → new_ary
map → Enumerator

Что здесь item, block и new_ary и как они связаны? Невозможно сказать, если вы не знаете реализацию или не можете как-то вывести ее из имени функции. Указать тип также сложно, поскольку new_ary зависит от того, что возвращает block, что, в свою очередь, зависит от типа item, который может отличаться для каждого элемента в массиве.

Часто вы также натыкаетесь на документацию, в которой говорится, что аргумент имеет тип Object, что опять же ничего не говорит вам, поскольку все является объектом.

У OCaml есть решение для этого, он поддерживает структурную типизацию, поэтому функция, которой требуется объект со свойством foo, равным String, будет считаться { foo : String } вместо конкретного типа. Но OCaml по-прежнему статически типизирован.

Стоит отметить, что это также может быть проблемой для языков со статической типизацией. Scala имеет очень общие методы для коллекций, что приводит к сигнатурам типа, например ++[B >: A, That](that: GenTraversableOnce[B])(implicit bf: CanBuildFrom[Array[T], B, That]): That, для добавления двух коллекций.

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

Вот почему я предпочитаю статическую типизацию;)

Редактировать Возможно, имеет смысл делать то же, что и Scala. На самом деле он не показывает вам сигнатуру типа для ++ по умолчанию, вместо этого он показывает ++[B](that: GenTraversableOnce[B]): Array[B], который не является общим, но, вероятно, охватывает большинство случаев использования. Таким образом, для карты Ruby она может иметь сигнатуру мономорфного типа, например Array<a> -> (a -> b) -> Array<b>. Это правильно только в тех случаях, когда список содержит только значения одного типа, а блок возвращает только элементы одного другого типа, но это намного проще для понимания и дает хороший обзор того, что делает функция.

Да, похоже, вы неправильно понимаете эту концепцию. Это не замена статической проверки типа. Это просто другое. Например, если вы конвертируете объекты в json (для их рендеринга клиенту), вас не волнует фактический тип объекта, если у него есть метод #to_json. В Java вам нужно будет создать IJsonable интерфейс. В Ruby никаких накладных расходов не требуется.

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

Буквально в другой день я видел, как программист rails с более чем 6-летним опытом жаловался в твиттере, что не может запомнить порядок параметров для alias_method: новое имя идет первым или последним?

Это противоречит обещанию Руби об интуиции.

Не совсем. Может это просто плохо написанная библиотека. В core ruby, осмелюсь сказать, все довольно интуитивно понятно.

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

Учтите, что выбор дизайна строго типизированных языков (C ++, Java, C # и др.) Требует строгих деклараций типа, передаваемого методам, и типа, возвращаемого методами. Это связано с тем, что эти языки были разработаны для проверки правильности аргументов (и поскольку эти языки скомпилированы, эту работу можно выполнить во время компиляции). Но на некоторые вопросы можно ответить только во время выполнения, и, например, C ++ имеет RTTI (интерпретатор типов времени выполнения) для проверки и обеспечения гарантий типов. Но как разработчик вы руководствуетесь синтаксисом, семантикой и компилятором для создания кода, который следует этим ограничениям типа.

Ruby дает вам возможность принимать динамические типы аргументов и возвращать динамические типы. Эта свобода позволяет вам писать более общий код (прочтите Степанов о STL и универсальном программировании) и дает вам богатый набор методов самоанализа (is_a ?, instance_of?, Response_to?, Kind_of?, Is_array? И др.), Которые вы можно использовать динамически. Ruby позволяет вам писать общие методы, но вы также можете явным образом применять дизайн по контракту и обрабатывать отказ контракта с помощью выбранных средств.

Да, вам нужно будет проявлять осторожность при объединении методов в цепочку, но изучение Ruby - это не просто несколько новых ключевых слов. Ruby поддерживает несколько парадигм; вы можете писать процедурные, объектно-ориентированные, универсальные и функциональные программы. Цикл, в котором вы сейчас находитесь, будет быстро улучшаться по мере того, как вы узнаете о Ruby.

Возможно, ваша озабоченность связана с предвзятым отношением к строго типизированным языкам (C ++, Java, C # и др.). Утиная печать - это другой подход. Ты думаешь иначе. Утиная печать означает, что если объект выглядит как a, ведет себя как a, то это a. Все (почти) является объектом в Ruby, поэтому все полиморфно.

Рассмотрим шаблоны (они есть в C ++, в C #, в Java они есть, в C есть макросы). Вы создаете алгоритм, а затем заставляете компилятор генерировать экземпляры для выбранных вами типов. Вы не разрабатываете по контракту с дженериками, но когда вы понимаете их силу, вы пишете меньше кода и производите больше.

Некоторые из ваших других проблем,

• сторонние библиотеки (драгоценные камни) не так сложно использовать, как вы боитесь
• Документированный API? См. Rdoc и http://www.ruby-doc.org/
• Документация Rdoc (обычно) предоставляется для библиотек.
• рекомендации по кодированию - для начала посмотрите в исходный код пару простых жемчужин
• соглашения об именах - как змеиный, так и верблюжий чехлы популярны

Предложение - непредвзято подойдите к онлайн-руководству, выполните самоучитель (http://rubymonk.com/learning/books/ хорошо), и у вас будут более конкретные вопросы.