Об одном нововведении в Perl 6

[jtraub]

Ну в приципе логично. Все это операторы равенства. Просто некоторые операторы равенства равнее других операторов равенства.

[khim]

Более интересно — являются ли они отношениями эквивалентности. Основная претензия к «как-бы типа равенству» в PHP заключается не в том, что есть == и ===, а в том, что == не является отношением эквивалентности (а операторы сравнения не являются отношениями порядка).

Насколько я знаю ничего подобного с 6ю опреаторами равенства в Perl6 нету.

[viv81ster]

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

[jtraub]

Приведите в качестве примера еще один ОО язык в котором также много операторов равенства.

[viv81ster]

Питон

[jtraub]

Давайте посмотрим. Я немного знаком с Питоном. Сколько там операторов равенства?

[viv81ster]

хм.
Посмотрел Java, C# там их тоже не особо много. В основном используется интерфейс для реализации сравнения в классе.

Перл по операторам переплюнул по ходу всех.

[jtraub]

Шпаргалка: www.python.org/doc/2.5.2/ref/operators.html

[el777]

Я заметил только «больше», «меньше», «равно», «не равно» а так же менее строгие «меньше либо равно», «больше либо равно».
Другой вопрос, что питон позволяет их переопределить для своих классов.
Вплоть до того, что если A и B — экземпляры некоего класса, то одновременно может выполняться такое:

>>> print A == B and A != B
True


Это говорит только об одном: программаст — ССЗБ.

[viv81ster]

Хотя вот Ruby еще

phrogz.net/ProgrammingRuby/language.html#table_18.4

[khim]

В любом лисп-подобном языке их будет масса. Так в языке Scheme есть "=", «char=?», «eq?», «eqv?», «equal?». В некоторых диалектах бываёт ещё варианты. Гораздо проще работать с десятком простых и предсказуемых операторов, чем с парочкой операторов, обладающих крайне запутанной семантикой. Конечно если ваша цель — написать работающую программу, а не срубить бабла на поддержке.

[grep0]

«Простых и предсказуемых» означает в том числе «имеющих предсказуемые и различимые названия». Довольно трудно вспомнить, чем отличаются «eq?», «eqv?» и «equal?»

[khim]

Совершенно нетрудно. Чем короче оператор, тем быстрее он работает и тем реже возвращает «true». «eq?» сравнивает только ссылки на объекты (самые простые объекты типа #t, #f или #popa собственно являются ссылками в таблицу символов и для них он тоже работает), «eqv?» сравнивает значения (то есть работает уже и для символов и чисел), «equal?» сравнивает структуры (рекурсивно). На практике «eqv?» используется редко, так как вам чаще всего нужно знать — тот ли это объект или другой или сравнивать числа (числовым операторам сравнения). Ни о каких автоматических преобразованиях типов речи не идёт никогда — а это очень важно.

Почему я так ненавижу автоматические преобразования типа? Потому что в 90% случаев они не нужны, так что в тех редких случаях где они нужны их несложно сделать и явно, а зато если неявное преобразование типа происходит там, где оно не нужно — вы имеете либо просто ошибку либо дырку в безопасности. Упростить себе жизнь в 1 случае из 10 за счёт усложнения в 9 случаях из 10 — кто ж вас умным назовёт? Пока PHP использовался для совсем простых страничек (100KB HTML+CSS, две строки на PHP) соотношение было обратным, но как только речь заходит о какой-нибудь несчастной гостевой книге — так соотношение начинает приближаться к 1-к-1 (и свидетельствует о том, что пора переходить на использование какого-нибудь языка программирования — хотя бы даже и Perl'а), а форумы уж точно на PHP делать не следует (если есть выбор: если у вас на хостинге есть только PHP и нету ничего больше, то куда деваться?), не говоря уже о бо́льших проектах.

[Irokez]

по-моему, ООП подходом было бы логичнее создать метод compare()

[KaLGaN]

There is more than one way to do it. :)

[el777]

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

>>> print A==B and A != B
True


[nimnull]

а можно увидеть реально рабочий пример на пайтоне — как добиться «A == B and A != B»? а то вы меня прям заинтриговали.

[Tagire]

эм, переопределить оба параметра на тру в любом случае?

[nimnull]

врядли. конъюнкция (она же логическое «и») будет давать true только если оба операнда будут true, во всех остальных случаях будет false. Соответственно нужно подобрать такую пару A и B чтобы они одновременно удовлетворяли обоим условиям == и !=. Поэтому меня это и заинтересовало.

[jtraub]

Пожалуйста.

In [1]: A = Eqt(1)

In [2]: B = Eqt(2)

In [3]: A == B
Out[3]: True

In [4]: A != B
Out[4]: True

In [5]: A==B and A != B
Out[5]: True

А код вот такой:

class Eqt:
    def __init__(self,p)
        self.param = p
    def __ne__(self, other):
        return True
    def __eq__(self, other):
        return True

[nimnull]

Спасибо, у меня тоже уже промелькнула мысль о переопределении операндов сравнения для классов =)

[el777]

Немного опередили :)
Фишка действительно в переопределении функций сравнения. Такой подвох хорошо виден в маленькой программе, а в большой с массой компонент надо быть внимательным. Впрочем, это верно для любого программирования, тот же C тоже допускает приколы типа

#define i j /* Have nice debug :) */

[Killy]

Периодическая таблица операторов ;)
www.ozonehouse.com/mark/blog/code/PeriodicTable.html

[jtraub]

Любопытно наблюдать за миграциями поста из /new/ на главную и назад :-)

[beartamer]

There Are Too Many Ways To Do It

[hellohaos]

почитал ссылку — все понятно.
к чему претензии?

[AlexPet]

думаю, дело в уязвленном самолюбии «похапе»-шников :) и в давних комплексах по этому поводу

[jtraub]

Думаю дело в том, что Perl 6 стал OO — Operators Oriented