- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
/**
* Determines equality based upon the contents of this Box instead of the box itself.
* As a result, it is not symmetric. Which means that for
*
* <pre name="code" class="scala">
* val foo = "foo"
* val boxedFoo = Full(foo)
* foo == boxedFoo //is false
* boxedFoo == foo //is true
* </pre>
*
* For Full and Empty, this has the expected behavior. Equality in terms of Failure
* checks for equivalence of failure causes.
*/
override def equals(other: Any): Boolean = (this, other) match {
case (Full(x), Full(y)) => x == y
case (Full(x), y) => x == y
case (x, y: AnyRef) => x eq y
case _ => false
}
rat4 20.09.2012 22:26 # 0
roman-kashitsyn 20.09.2012 22:38 # 0
LispGovno 21.09.2012 07:20 # −1
LispGovno 21.09.2012 08:59 # −1
rat4 21.09.2012 09:19 # 0
Full - лифтовый Box
LispGovno 21.09.2012 09:42 # −1
roman-kashitsyn 21.09.2012 11:40 # +1
LispGovno 21.09.2012 12:04 # 0
За исключением val (что не суть), очень похоже на Nemerle. Хорошо сделали. Порт скал`ы под .NET, есть?
LispGovno 21.09.2012 12:07 # −1
Ниже увидел ваше предположение. Глуповато вышло. Чем боролись, на то и напоролись.
roman-kashitsyn 21.09.2012 12:45 # 0
Да.
> почему не добавить эти методы в сам Option
Всё из демо (кроме openOrThrowException) можно сделать и с обычной Option, она вполне себе функциональна. Просто лифтовцам нужно было много утилит, которые добавить в Option нельзя, манки-патчинг в скале запрещён.
http://www.scala-lang.org/api/current/scala/Option.html
> Порт скал`ы под .NET, есть
Говорят, можно писать на scala прямо в Visual Studio
http://www.scala-lang.org/node/10299
LispGovno 21.09.2012 13:20 # −1
Извлечь из монады или кинуть исключение. Это круто вообще. В Немерле такого вроде нет( Да и вообще поддержки обобщения мейби до контенера - тоже вроде нет. (
>Просто лифтовцам нужно было много утилит, которые добавить в Option нельзя
Это типа тех, что ты показал, например map и так далее?
>манки-патчинг в скале запрещён.
Методы-расширения как под .NET?
Ну да, согласен. В Option для Nemerle можно это добавить и вручную.
roman-kashitsyn 21.09.2012 14:14 # 0
LispGovno 21.09.2012 14:53 # −1
>Если сходить по ссылке
Она не кликается.
На самом деле спасибо.
roman-kashitsyn 21.09.2012 14:58 # 0
Тогда maybeSmth.toList.map(_.name) вернёт список, а не Option, как должно быть. Плюс лишний объект, минус более простая и быстрая реализация map.
LispGovno 21.09.2012 15:19 # −1
roman-kashitsyn 21.09.2012 22:52 # 0
LispGovno 21.09.2012 23:13 # −1
Антиоверинженеринг:
И Box почти не нужен.
roman-kashitsyn 22.09.2012 00:22 # 0
LispGovno 22.09.2012 00:44 # −1
Ждем шизофреничного предложения Options<Options<T>>.
roman-kashitsyn 22.09.2012 00:49 # +2
LispGovno 22.09.2012 00:59 # −1
>join, т.е. преобразование M<M<T>> => M<T>
Ничего себе как продумано. Полная аналогия со списком. Уважение создателю. Вот что значит системный подход.
>Со списками чуть поинтереснее, иногда нужен именно List<List<T>>.
Ну так и не вызывай join. Какие проблемы?
PS: Пост ниже 154585 я написал несколько раньше этого поста.
LispGovno 22.09.2012 00:46 # −1
roman-kashitsyn 22.09.2012 13:47 # 0
bool это тоже частный случай int, но с ним же лучше, чем без него
LispGovno 22.09.2012 16:11 # 0
roman-kashitsyn 21.09.2012 15:01 # 0
Методы-расширения ещё ладно, хотя мне они не нравятся. Я скорее о возможности напрямую изменить поведение базовых классов, как в Ruby.
LispGovno 21.09.2012 15:05 # −1
roman-kashitsyn 22.09.2012 01:15 # +3
Vindicar 22.09.2012 10:38 # +4
это даже круче чем #define TRUE FALSE
LispGovno 21.09.2012 15:02 # −1
roman-kashitsyn 21.09.2012 15:10 # 0
Плюс и минус такого решения в том, что в любом случае будут использоваться только стандартные механизмы языка, никакого метапрограммирования или особого синтаксиса. Ну, и без хаскеловской лени временами будет не очень круто, хоть и не критично (в Scala вроде можно объявить ленивую инициализацию аргумента функции, т.е. в выражении x(y + 7) часть (y + 7) будет упакована в thunk и вычислена при обращении внутри x).
LispGovno 21.09.2012 15:18 # −1
Скала под .нет юзабильна? IDE с авто дополнением кода? Демонстрация выведенных типов по подводу мыши? Ну и может формошепка есть? Ну и под Java тоже самое есть?
roman-kashitsyn 21.09.2012 15:24 # 0
LispGovno 21.09.2012 15:39 # −1
Проще язык чем джава - найти сложно. C# и то сложнее. Если уж на то пошло, то одни из самых сложных языков для IDE - Nemerle с его диким выводом типов и диким метапрограммированием или просто дикий С++.
При этом в Немерле отличная иде, не уступающая C#. Ну и для С++ найти хорошую IDE не представляет труда, если искать, в том числе и среди плагинов.
TarasB 21.09.2012 16:04 # +2
wvxvw 21.09.2012 16:37 # +1
defecate-plusplus 21.09.2012 16:56 # 0
TarasB 21.09.2012 19:10 # 0
ну да
TarasB 21.09.2012 19:10 # 0
wvxvw 21.09.2012 21:36 # 0
3.14159265 02.10.2012 13:52 # 0
myaut 21.09.2012 00:29 # +1
roman-kashitsyn 21.09.2012 00:31 # 0
myaut 21.09.2012 00:34 # 0
Кстати возможность сломать семантику операторов - один из аргументов Линуса Торвальдса против C++ в ядре.
roman-kashitsyn 21.09.2012 00:43 # 0
Почему так реализовали equals в самом часто используемом классе в общем-то неплохого фрэймворка - тайна. Видимо, Поллак был под веществами.
LispGovno 21.09.2012 07:22 # −1
Догадовался, что они есть, но что-за условия, где прочитать?
roman-kashitsyn 21.09.2012 07:54 # +2
LispGovno 21.09.2012 08:57 # −1
a==b => b==a
a==b && b==c => a==c
Что ещё?
govnomonad 21.09.2012 11:07 # +2
LispGovno 21.09.2012 11:08 # −1
LispGovno 21.09.2012 11:59 # 0
a < a => ложь
a < b && b < c => a < c
Где-то ошибся или что-то ещё забыл?
wvxvw 21.09.2012 12:46 # +2
a < b -/-> b < a (relation is not simmetrical)
a < b /\ b < c --> a < c (relation is transitive)
a < a --> a < a (vacuously true :), so, reflexive)
Нужно еще учитывать, что такие операции определены не для всех множеств (например, деление на множестве натуральных чисел не определено в этом плане).
wvxvw 21.09.2012 12:54 # +1
LispGovno 21.09.2012 13:07 # +1
Это что-то из корабельного журнала капитана очевидность?
> a < a --> a < a
Это я совсем не понял...
TarasB 21.09.2012 13:18 # +13
"Проснулся в 8.00. Было утро."
или
"Мы плыли по морю. Кругом была вода."
wvxvw 21.09.2012 13:59 # +1
vacuous truth - такая истинность, которую нельзя опровергнуть, т.как нет возможности найти пример, который бы показывал обратное утверждаемому. Для простоты будем считать, что a - натуральное число, тогда нет такого a, при котором P(a < a) = true, соответственно, доказать, что P(a < a) ~= P(a < a) не получится, т.как нам нужен, по определению, такой предикат P() который дает позитивный результат.
Но это, вобщем-то, была шутка...
LispGovno 21.09.2012 14:54 # −1
TarasB 02.10.2012 14:14 # 0
а вот a < a --> a < a нету, потому что ко
да, в изначальном определении свойства говорились не про > а именно про >=
3.14159265 02.10.2012 13:46 # +2
Ох бля. В джаве настолько хуёвые нативные equalsы и настолько много хинтов, граблей, правил, и исключений из них - чтобы реализовать правильно equals - это вообще целая наука. Лень даже вдаваться в детали.
Проблема настолько масштабна, что апачи даже написали специальную фабрику под названием EqualsBuilder.
Только за один equals жабу можно смело называть говном.
One does not simply implement correct equals in Java.
roman-kashitsyn 21.09.2012 00:49 # +5
А как вам этот кусочек?
roman-kashitsyn 21.09.2012 00:57 # 0
LispGovno 21.09.2012 07:25 # +5
Ты подарил мне тот редкий момент, когда ожидаемое совпадает с действительным...
scriptin 21.09.2012 00:42 # 0
roman-kashitsyn 21.09.2012 01:08 # 0
scriptin 21.09.2012 02:02 # 0
roman-kashitsyn 21.09.2012 07:52 # 0
zim 21.09.2012 14:41 # 0
LispGovno 21.09.2012 22:01 # 0
>foo == boxedFoo //is false
это скомпилируется? this же имеет тип бокс. А получается, что левая часть разбоксирована.
>(this, other) match{
И почему такой странный матчинг?
match(this, other){
roman-kashitsyn 21.09.2012 22:50 # 0
В языках с OOP, где есть наследование, нельзя ограничивать тип оператора ==:
LispGovno 21.09.2012 22:20 # 0
Понятно, что там ещё со ссылками разница какая то есть, но с моим знанием тамошней системы типов, опустим этот момент.
LispGovno 21.09.2012 23:21 # 0
roman-kashitsyn 22.09.2012 00:24 # 0
(x, y) => x eq y
LispGovno 22.09.2012 00:39 # 0
Знаю, что в жабе == сравнивает по адресу ссылки, а equals сравнивает по значению. Выше я писал безотносительно этого.
А уж что здесь eq значит - не знаю.
roman-kashitsyn 22.09.2012 00:44 # +1
LispGovno 22.09.2012 00:50 # 0
http://govnokod.ru/11813#comment154573
Только обозначения чуть сменим:
Empty эквивалентно null
Full эквивалентно конкретному не нулевому значению.
LispGovno 22.09.2012 00:51 # 0
roman-kashitsyn 22.09.2012 00:52 # +1
LispGovno 22.09.2012 01:27 # 0
Я не согласен. Не монадично это.
Ты не коробки сравнивать должен, а элементы, что лежат в коробке.
Для начала воспользуемся многолетним опытом исследователей из других областей.
Если мне не изменяет память (поправьте меня если я ошибусь) взгляним на NAN (Not a number) в FPU и null в SQL.
Если x - любое, то
1)x == NAN => false
NAN == x => false
NAN == NAN => false
зато isNAN(x) вернет всеж интересующий ответ на вопрос.
2)null ведет себя аналогично в SQL запросах.
x == null => false
null == x => false
null == null => false
Если ты боишься, что у тебя будут проблемы с поиском из-за нарушения рефлексии, то это не так.
Монада, например, хранит или объект\объекты или провал прошлого вычисления.
map1.find(Empty) должа вернуть Empty, а не найти закинутое каким-то идиотом по ключу Empty некое значение Full ("kokoko") например (если это ассоциативный массив).
Аналогично если расширять операции, то:
Empty*x = Empty
Также как и
NAN*х = NAN. Если сменить настройки FPU, то понятно, что нам выкинут исключение и по сути все нижележащие вычисления не обработаются, что посути тот же NAN (Empty), протащенный через всю цепочку вычислений до точки обработки в монадах.
LispGovno 22.09.2012 01:32 # 0
roman-kashitsyn 22.09.2012 01:47 # 0
В методе equals класса Box нужно сравнивать именно коробки.
LispGovno 22.09.2012 02:32 # 0
http://www.youtube.com/watch?v=3R9K_7xuFLQ
LispGovno 22.09.2012 02:42 # 0
Где аргументы? Не нужно прикрываться бумажкой мол вот стандарт и мы ему бездумно следуем. Запомните, в ресерчевых областях это не работает.
LispGovno 22.09.2012 16:17 # 0
Так что совершенно логично, то одна пустота не равна другой.
LispGovno 22.09.2012 02:45 # 0
LispGovno 23.09.2012 20:19 # 0
roman-kashitsyn 23.09.2012 21:00 # 0
LispGovno 23.09.2012 21:18 # 0
roman-kashitsyn 23.09.2012 21:25 # 0
LispGovno 23.09.2012 21:32 # 0
roman-kashitsyn 24.09.2012 14:28 # +1
LispGovno 24.09.2012 15:16 # 0
Что-то типа как в F# полагаю?
http://msdn.microsoft.com/en-us/library/dd233182.aspx
Одна из реализаций этих методов seq:
http://msdn.microsoft.com/en-us/library/dd233209.aspx
или query:
http://msdn.microsoft.com/en-us/library/hh225374.aspx
Но по дефолту каких либо других монад реализованных нет.
В немерле похожим образом, только конструкция монадического сахара введена через метапрограммирование, немного пошире и по дефолту реализованы многие монады.
roman-kashitsyn 24.09.2012 15:30 # +2
Там нет никакого полиморфизма, по for тупо генерится код с map, flatMap и filter, а уж потом проходит проверка типов. Определи в своей монаде эти методы, и можешь смело юзать for.
LispGovno 24.09.2012 15:39 # 0
LispGovno 23.09.2012 21:27 # 0
>CokleisliArrow
Это те стрелки, что в хаскеле выглядят в виде операций? По моему, сам будешь не рад, если ими будешь пользоваться...
LispGovno 23.09.2012 21:29 # 0
> List(1, 2).foldRightM
Вот ты на хаскель наезжал, что мол много функций с префиксом м специально для монад, а тут таже самая проблема
roman-kashitsyn 23.09.2012 21:33 # 0
LispGovno 23.09.2012 21:37 # 0
LispGovno 23.09.2012 21:33 # 0