Здравствуйте, Cyberax, Вы писали:
>> C>То есть, контракты можно представить в виде набора аксиом. Для того же >> C>sqrt у нас есть аксиома "sqrt(x)*sqrt(x)=x". >> Согласись, что такой конктракт уже ничего общего с тем о чем говорил >> Ваня не имеет. C>Да, согласен.
Ну, так мы с Синклером как раз и говорим, о том, что нельзя с мерилом из ООП, где понятие контракта очень специфично, подходить к программированию в целом. Так же надо понимать, что правла вроде обсуждаемого здесь имеют смысл только если твое видение мира ограничено ООП-ом. И его опять же нельзя применять на программирование в целом. Так что если нарушение подобных правил делается не по глупости, а просто потому что люди выбрали другой концептуальный подход, то это нормально и в сущьности никаких нарушенпй нет, так как само правило уже не применимо.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, VladD2, Вы писали:
VD>>Ты почитай внимательно обсуждение. IB>
IB>Контракты и интерефейсы тоже догмы той идиологии
IB>Это кто-то другой за тебя писал?
Это было сказано в ответ на твою попытку перевести разговор на обсуждение контрактов. Кстати, ты все же почитай обсуждение до конца. Тут как раз очень хорошо было показано, что твое понимание контракта очень узко. И что в том же ФП контракты тоже есть, но они другие и их нелзя выразить средствами ООП.
VD>> Я говорил о том, что применение данного принципа становится бессмысленным как только ты отходишь от приципов ООП IB>А я говорил, что нет, по пятому кругу пойдем?
Ты говоришь совершенно бездоказательно и твои суждения рушатся на совершенно банальных вещах. К сожалению объяснить тебе ничего не удастся так как ты видел только одну сторону медали (ООП).
VD>> Иначе разговор не получится. IB>Да он и так не очень-то.
Здравствуйте, VladD2, Вы писали:
VD>Это было сказано в ответ на твою попытку перевести разговор на обсуждение контрактов.
Я не пытался перевести разговор, я с самого начала о них говорил.
VD>Тут как раз очень хорошо было показано, что твое понимание контракта очень узко.
=)
Я формулировочку контракта специально упростил, чтобы тебе понятнее было. И в ее ширину вполне влезает все что было показано.
VD> И что в том же ФП контракты тоже есть, но они другие и их нелзя выразить средствами ООП.
Где я говорил, что контракт надо выражать средствами ООП? Я говорил совершенно обратное.
VD>К сожалению объяснить тебе ничего не удастся так как ты видел только одну сторону медали (ООП).
Влад, я устал. Давай сойдемся на том что я и ООП-то не очень знаю и покончим с этим.
Здравствуйте, VladD2, Вы писали:
VD>Ну, так мы с Синклером как раз и говорим, о том, что нельзя с мерилом из ООП, где понятие контракта очень специфично, подходить к программированию в целом.
С ОО-мерилами обычно подходят к декомпозиции задачи. Притом, подходить так начали задолго до появления самого "ООП". Так что, по всей видимости, кое-что очень рациональное в таком подходе есть, как ни крути.
VD>Так же надо понимать, что правла вроде обсуждаемого здесь имеют смысл только если твое видение мира ограничено ООП-ом. И его опять же нельзя применять на программирование в целом.
LSP прекрасно работает начиная с того момента, когда мы определяем некие "слоты" для дальнейшего расширения системы. Совершенно не важно, как именно мы будем определим сами "слоты": как соглашения для функций (сигнатуры и требования к функциям), или для классов (интерфейсы в смысле "interface"). Когда соглашения слота будут определены, следующим шагом с большой вероятностью этот набор будет объявлен "типом", ибо так проще ссылаться на него в дальнейшем. А те внешние "штуки", которые должны будут подключаться к этому слоту — будут называться реализациями типа, или же — подтипами. Вуаля! Здравствуй, критерий допустимости подстановки Лисковой.
VD>Так что если нарушение подобных правил делается не по глупости, а просто потому что люди выбрали другой концептуальный подход, то это нормально и в сущьности никаких нарушенпй нет, так как само правило уже не применимо.
Естественно, нет необходимости блюсти LSP, если не возникает тех самых "слотов" расширения.
PS.: Ты это, бросай уже на "догмомировзгляды" ссылаться. Это всё забавно, конечно, но ощущение возникает, что читателю мозги промыть пытаются.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, palm mute, Вы писали: PM>>Понятие контрактов вполне применимо в ФП. Смущает отсутствие классов/интерфейсов? Их можно заменить модулями ML или классами типов Haskell. PM>>Контракт в ФП — это логическое утверждение об алгебраических свойствах функции или семейства функций. Например, применив функцию reverse дважды, мы должны получить исходный список. S>Угу. Это все здорово, но не мог бы ты применить принцип подстановки Лисков к функции reverse и заменить ее чем-то другим? PM>> Функция сравнения, передаваемая в функцию сортировки, должна быть рефлексивной, транзитивной и антисимметричной. S>Ну, при этом у нас нет такого понятия как "базовая рефлексивная функция", которое можно использовать как базу для наследования/субтипизации.
Ну, если вернуться к монадическим законам,
1. (return x) >>= f == f x
2. m >>= return == m
3. (m >>= f) >>= g == m >>= (\x -> f x >>= g)
то таки да, в Хаскелле любой тип, являющийся экземпляром класса Monad должен им удовлетворять. Правда это не проверяется на языковом уровне, но palm mute давал ссылки на внешние системы проверки.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, LaptevVV, Вы писали:
LVV>>Обратное — неверно! Всякий будильник (производный тип) является часами (базовый тип), но не всякие часы — будильник.
КЛ>Я бы сказал несколько иначе. Существуют две функции:
КЛ>1) Измерение времени. КЛ>2) Выдача сообщения (например, звонка) по сигналу.
КЛ>Эти функции могут быть реализованы как в одном устройстве, так и в разных. Это я к тому, что далеко не всякий будильник является или может являться часами.
Любой будильник измеряет время, он его может не показывать, это как раз комбинация тех двух устройств : измерителя и сигнала
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Ок, слово "спецификация" тебя устроит? )
Если нам не помогут, то мы тоже никого не пощадим.
Мы уже победили, просто это еще не так заметно...
