Переопределение Ruby & amp; и | методы не требуются. оператор? [Дубликат]

Поскольку синтаксис Ruby был разработан так, чтобы выглядеть примерно так, как популярные языки OO, и те, кто использует метод dot, используют методы вызова. Язык, на котором он заимствовал свою объектную модель от Smalltalk, не использовал точки для сообщений, и на самом деле имел довольно «странный» синтаксис, который многие люди находили вне помещения. Ruby был назван «Smalltalk с синтаксисом Algol», где Algol - это язык, который дал нам соглашения, о которых вы говорите здесь. (Конечно, на самом деле больше различий, чем просто синтаксис Algol.)

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

конечно другие варианты:

• Lisp вообще не имеет операторов . +, -, ::, >, = и т. д. являются просто нормальными именами юридических функций (фактически имена переменных), как foo или bar?

  (plus 1 2)
  (+ 1 2)
  

• Smalltalk почти не имеет операторов. Единственным специальным корпусом Smalltalk является то, что методы, состоящие только из символов оператора, не должны заканчиваться двоеточием. В частности, поскольку операторов нет, все вызовы методов имеют одинаковый приоритет и оцениваются строго слева направо: 2 + 3 * 4 - 20, а не 14.

  1 plus: 2
  1 + 2
  

• Скала почти не имеет операторов. Точно так же, как Lisp и Smalltalk, *, -, #::: и т. Д. Являются просто юридическими именами методов. (Фактически, они также являются легальным классом, признаком, типом и именами полей.) Любой метод может быть вызван либо с точкой, либо без нее. Если вы используете форму без точки, и метод принимает только один аргумент, вы также можете оставить скобки. Однако Scala имеет приоритет, хотя он не определяется пользователем; он просто определяется первым символом имени. В качестве добавленного твиста имена операторов-операторов, заканчивающиеся двоеточием, инвертированы или право-ассоциативны, то есть a :: b эквивалентно b.::(a), а не a.::(b).

  1.plus(2)
  1 plus(2)
  1 plus 2
  1.+(2)
  1 +(2)
  1 + 2
  

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

  plus 1 2
  1 `plus` 2
  (+) 1 2
  1 + 2
  

Нет никакой конкретной причины, по которой Ruby не может поддерживать пользовательские операторы в стиле, подобном Scala. Там есть причина, по которой Ruby не может поддерживать произвольные методы в позиции оператора, просто потому, что

foo plus bar

уже уже юридический, и, таким образом, это быть обратным-несовместимым изменением.

Еще одна вещь, которую следует учитывать, - это то, что Ruby на самом деле не был полностью разработан заранее. Он был разработан посредством его реализации. Это означает, что во многих местах реализация протекает. Например, нет абсолютно никакой логической причины, почему

puts(!true)

является законным, но

puts(not true)

- нет. Единственная причина , почему это так, заключается в том, что Matz использовал парсер LALR (1) для анализа языка, отличного от LALR (1). Если он сначала разработал язык , он бы никогда не выбрал парсер LALR (1), и выражение было бы законным.

Функция Refinement в настоящее время обсуждается на ruby-core, является еще одним примером. То, как оно указано в настоящий момент, сделает невозможным оптимизировать вызовы методов и встроенные методы , даже если рассматриваемая программа фактически не использует Refinement s вообще , С помощью простой настройки он может быть столь же выразительным и мощным, и гарантировать, что стоимость пессимизации возникает только для областей, которые на самом деле используют Refinement s. По-видимому, единственная причина , почему была указана именно так: a) было проще прототипировать этот путь, и b) YARV не имеет оптимизатор, поэтому никто даже не потрудился подумать о последствиях (ну, кроме Чарли Оливера Нуттера).

Итак, в основном вопрос, который у вас есть о дизайне Ruby, ответ почти всегда будет либо «потому что Мац сказал так» или «потому что в 1993 году было проще реализовать этот путь».