Операторы в руби

Сегодня я вам расскажу о том, чего на самом деле нет - о операторах в руби. Вы можете спросить: а как же +, -, * и т.п. Так вот, их нет. И ложки тоже нет кстати.
Есть только [strike]матрица[/strike] объекты. Методы - тоже объекты, а все эти операторы - на самом деле вызов методов. Но не все так просто, как на первый взгляд Поэтому в руби есть приоритет операторов, некоторые выполняются раньше, некоторые позже. Но я специально не буду вам о них рассказывать - математические операторы исполняются точно так, как мы привыкли в школе, - деление и умножение раньше чем сложение и т.п. Остальные приоритеты - совсем не очевидны, поэтому лучше их группировать при помощи скобок
В общем знайте, когда вы видите что то похожее на оператор - на самом деле это вызов метода и синтаксический сахар, которым так славен руби. Да они по-особому обрабатываются интерпретатором, но они остаются самыми настоящими методами, со всеми вытекающими.

Но что нам это дает? Возможность [strike]останавливать пули[/strike] определить \ переопределить операторы и получить отличный код.
Допустим нам нужно написать класс урона, ну вы знаете - "Алистер нанес скелету 20 единиц святого урона" Уже хорошо, теперь нужно добавить атрибуты - для простоты оставим единицы и природу. Почему я использовал attr_reader а не attr_accessor - я долго мучался, как же мне стоит писать, но в итоге решил - если предполагается установка атрибута из вне - использую attr_accessor, если нет - attr_reader и работаю с инстанс переменными (если мне нужно атрибут установить).
Теперь мы можем написать: А сколько нанесли Алистер и Мориган вместе? Нужно добавить сложение! Сложение не должно изменять текущий объект, поэтому создаем новый. Points в новом объекте будут равны сумме points в исходных объектах, nature - тут уже на выбор разработчика. На мой взгляд, если, у урона природа одна, то и nature для такого объекта должен возвращать собственно строку природы. Если же несколько - то от массива не уйдешь. Обратите внимание, как я использовал flatten, это мне позволяет не думать, сколько там природ у слагаемого. Метод в таком виде - пример утиной типизации - если в двух словах то нам не важно, какой объект передается методу, мы предполагаем что этот объект скорее всего принадлежит классу Damage "Если кто то крякает как утка и выглядит как утка - значит это утка" (c) - отсюда название такого подхода. Плюс тут в том, что кода меньше, ну а минус - иногда получаются такие веселые баги, что век не поймаешь. Поэтому я почти всегда стараюсь хоть как то валидировать то, что ко мне пришло в метод. Это пример защитного программирования. Идея в том, что лучше сразу сообщить о ошибке, ведь чем раньше вы обнаружите ошибку - тем дешевле ее исправить.

Хорошо, а что если на цели дебафф, увеличивающий урон вдвое? А если бафф, уменьшающий урон?
Теперь мы можем сделать так:
Ну так кто круче, Алистер или Морриган? Кто нанес больше урона? Нам нужны методы сравнения >, <, <=, == и т.д. Для начала нужно решить, будет ли влиять природа на сравнение урона? Вспоминая свои годы жизни в WoW, я думаю что нет. Будем сравнивать только points. Мы можем сами определить каждый из этих методов сами, а можем пойти легким путем. Comparable - это миксин из стандартной библиотеки, включив его мы получаем сразу все методы сравнения в классе. Но мы должно определить последний на сегодня оператор <=> (Лодочка). Этот метод должен возвращать -1 когда объект меньше, чем предоставленный, 0 когда объекты равны, 1, когда больше. (Мы же пойдем совсем легким путем и просто вызовем <=> у атрибута points, ведь это число).
В итоге у нас получился полный класс:


И вот как мы его используем: В общем всем теперь ясно, что Алистер круче, а Морриган желаю быть добрее.
Так же, определив методы равенства в нашем классе, мы получаем доступ к другим фишкам, которые на этих методах основываются. На ум приходят только массивы, но уверен что есть еще.
И для тех кто дочитал до сюда - бонус! Два самых мутных оператора в руби [] и []=, ведь аргументы для этих методов передаются по особому:


Это все, что я хотел сказать, спасибо за внимание!

Сначала говоришь, что операторов нет... А потом утверждаешь, что у оператор есть приоритет...
В целом согласен, что у Руби такой синтаксис, что в итоге перегрузка операторов выглядит как просто объявление метода в принципе, но отличия все же есть.
Как ты заметил - приоритет, обычные методы так не делают... вроде бы...
Нельзя определить метод plus и потом швыряться им как Да, ты сказал, что синтаксический сахар, дело обычное, но все же есть набор методов, для которых позволен этот сахар. И есть они ни что иное как операторы.
Но чую, что ты имел ввиду, что они просто являются методами, и я тут ни за что на тебя напал
Пример, конечно, показательный, но немного пугает. Можно сложить гигантский урон не очень хорошего элемента, а затем впихнуть единичку, на которую у противника слабость... Но лучше чем обычные комплексные числа
А чтобы в итоге не выглядело, что я просто жалуюсь, то я дам ссыль на сайт с приоритетами, для ленящихся гуглить Приоритеты .
А вообще хотел бы придраться немного к контенту. Использование оператора <=> в методе max указано вскользь в коде. Можно было бы явнее описать использования таких операторов по умолчанию (если не задана другая функция) например при сортировке массива. Ну и обратить внимание на то, что можно подобные функции писать самому, опираясь на эти операторы, и они все равно будут довольно гибкими. /cheers

1) Ну хотя бы с тем что Алистер круче Морриган ты согласен, это радует.
2) Я приследовал две цели - показать что операторы в руби это методы и то как их можно переопределить и использовать. Не вина метода + что интерпретатор может распознавать его вызов без точки . Но это действительно самые настоящие методы, и это не перезагрузка операторов так выглядит, а самое настоящее определение самого настоящего метода. Ты можешь его получить при помощи method, увидеть в public_methods, вызвать при помощи __send__ и public_send, эти методы наследуются, подмешиваются и т.п. и т.д. Я допишу это в начальный пост.
3) Перечитал примеры и понял что их недостаточно в части про <=>, добавлю в начальный пост (я просто хотел показать как подключив один миксин и определив один метод вы можете получить целый вкусный кусок функциональности за бесплатно).
4) Как ты мог заметить, мультипликаторы для урона Алистера и урона Морриган я применил до того как сложил их. Естественно, в такой реализации все мультипликаторы должны быть применены до складывания урона.

Спасибо за конструктивную критику!

Ну, сложение уронов штука сложная, т.к. должна происходить в контексте сопротивлений цели. Тут "операторы" не очень подходят (разве что сделать операторы с разными классами: существо - урон, или существо + урон как лечение. Смущает только то, что придется дублировать существо с иным значением хп, ибо менять значение операнда плохой, очень плохой тон), но не стоит из-за этого менять пример.
Я в основном к тому, что в тех же сях перегрузка оператора выглядит как определение функции, правда можно ли их потом вызвать через точку - не проверял. Но самое главное - я думаю что мы от самого термина "оператор" не откажемся, ибо имеет много синтаксических сходств с другими ЯП, да и Руби к ним относится по особому. Но посыл понял - сформировать более верное представление (что хоть операторы и особенные с виду, в итоге они просто методы с подходящим именем)
И, извини слоупока, есть же тема операторов [](key) и []=(key, value). Новичкам может быть непрозрачно, особенно с учетом продвинутого сахорка (значение ключа между именем функции). Но не факт, что потребуется, возможно они у нас смышленые

Добавил описание [] и []= как бонус в самом конце, они просто немного мутноваты