Sinclair wrote:
> C>нас есть полугруппа, моноид, группа, кольцо, тело, поле. При этом, все
> C>теоремы для полугруппы будут выполняться, если вместо нее взять группу,
> C>или, например, алгебраическую структуру с одной из операций поля.
> Я себе совершенно не представляю, что означает "взять вместо полугруппы
> группу".
Если кратко, то полугруппа — это множество с определенной на нем
ассоциативной бинарной операцией. Группа — это множество с ассоциативной
бинарной операцией, причем в нем еще существует нейтральный элемент и
для каждого элемента (кроме нейтрального) существует обратный элемент.

> C>То есть, контракты можно представить в виде набора аксиом. Для того же
> C>sqrt у нас есть аксиома "sqrt(x)*sqrt(x)=x". Поэтому любой *объект*,
> О! Объект. Что есть объект? В ФП объектов нет. Есть /функции/, есть
> структуры. Объект в ООП является сущностью, обладающей идентичностью,
> поведением, и состоянием.
Я имел в виду "объект" в более широком смысле. Как синоним для слова
"фигня"

> C>который выполняет эти аксиомы будет нам подходить. Например, мы можем
> C>взять sqrt, использующий метод аппроксимаций Ньютона или fastsqrt из
> C>сырцов Q3, а может даже sqrt, использующий статистические вычисления.
> А, пардон, /зачем/? И к чему это приведет? Напомню, что Барбара
> выдвигает требования к классам объектов. Что, мы сможем благодаря этому
> доказать, что /одна/ из функций sqrt является в каком-то смысле
> /наследником/ другой?
Не обязательно. Например, у нас может быть обычный арифметический sqrt и
sqrt, поддерживающий комплексные числа. Но для случая положительных
вещественных чисел комплексный sqrt будет вести себя как и арифметический.

> Нет, не сможем. А уж если fastsqrt вернет
> /неточный/ результат, то это вообще испортит нам всю малину — ведь мы
> сможем таки отличить в клиенте "настоящий" sqrt и переданный нам эрзац.
> Нарушаться будет соотношение sqrt(x)^2 == x.
В программировании "==" — это приблизительная операция

> Ок, ну, наверное, единственное что можно сделать в ФП в стиле Лисков —
> это /доопределить/ функцию, которая ранее работала с неким множеством,
> на более широком множестве. Ну как там определяют Г(x), которая для
> натуральных x сводится к факториалу, но в отличие от факториала
> определена на всех комплексных числах. Наверное, так.
Ну да, примерно так. Кстати, забыл сказать, что наследование контрактов
используется в системах с доказательством корректности кода.

Здравствуйте, palm mute, Вы писали:

PM>Понятие контрактов вполне применимо в ФП.

Контракт как популярный термин был введён в SOA и обозначает формальное соглашение по взаимодействию между сервисами, независимое от платформ и языков программирования. Например, контракты для веб-сервисов описываются с помощью WSDL. В последнее время этот термин полюбился некоторым товарищам и они его пытаются применять с умным видом ко всему, что можно назвать публичным интерфейсом. Пока что кроме путаницы это ничего не даёт.

Здравствуйте, IT, Вы писали:

PM>>Понятие контрактов вполне применимо в ФП.
IT>Контракт как популярный термин был введён в SOA и обозначает формальное соглашение по взаимодействию между сервисами, независимое от платформ и языков программирования.
Ок, примем такое определение. Тогда понятие контракта применимо к ООЯ не больше и не меньше, чем к ФЯ, т.к. по определению, контракты от языков не зависят. Мне все-таки кажется, что Sinclair не о тех контрактах говорил.

Здравствуйте, palm mute, Вы писали:
PM>Понятие контрактов вполне применимо в ФП. Смущает отсутствие классов/интерфейсов? Их можно заменить модулями ML или классами типов Haskell.
PM>Контракт в ФП — это логическое утверждение об алгебраических свойствах функции или семейства функций. Например, применив функцию reverse дважды, мы должны получить исходный список.
Угу. Это все здорово, но не мог бы ты применить принцип подстановки Лисков к функции reverse и заменить ее чем-то другим?
PM> Функция сравнения, передаваемая в функцию сортировки, должна быть рефлексивной, транзитивной и антисимметричной.
Ну, при этом у нас нет такого понятия как "базовая рефлексивная функция", которое можно использовать как базу для наследования/субтипизации.

Здравствуйте, Sinclair, Вы писали:

S>Угу. Это все здорово, но не мог бы ты применить принцип подстановки Лисков к функции reverse и заменить ее чем-то другим?
Я могу передать различные реализации функции reverse.
PM>> Функция сравнения, передаваемая в функцию сортировки, должна быть рефлексивной, транзитивной и антисимметричной.
S>Ну, при этом у нас нет такого понятия как "базовая рефлексивная функция", которое можно использовать как базу для наследования/субтипизации.
Зато мы может ввести понятие частично упорядоченного множества и требовать, чтобы функция сравнения задавала отношение частичного порядка. А затем ввести подтип — вполне упорядоченное множество. А затем наплодить реализаций этого интерфейса для чисел, строк, множеств и т.д.

В противном случае что получается?

class List<T> {
  public void Sort (
    IComparer<T> comparer
  )
}

module List = struct
  val sort : ('a -> 'a -> int) -> 'a list -> 'a list
end

К comparer, значит, LSP применим, а к первому аргументу List.sort — нет? В чем принципиальная разница?

IT wrote:
> Контракт как популярный термин был введён в SOA и обозначает формальное
> соглашение по взаимодействию между сервисами, независимое от платформ и
> языков программирования.
Hint: термин "контракты" в Eiffel появился, эдак, в начале 90-х.

Здравствуйте, Cyberax, Вы писали:

>> Контракт как популярный термин был введён в SOA и обозначает формальное
>> соглашение по взаимодействию между сервисами, независимое от платформ и
>> языков программирования.
C>Hint: термин "контракты" в Eiffel появился, эдак, в начале 90-х.

В юриспруденции он появился ещё раньше. Тем не менее до знакомства с SOA его никто не использовал.

IT wrote:
>> > Контракт как популярный термин был введён в SOA и обозначает формальное
>> > соглашение по взаимодействию между сервисами, независимое от платформ и
>> > языков программирования.
> C>Hint: термин "контракты" в Eiffel появился, эдак, в начале 90-х.
> В юриспруденции он появился ещё раньше. Тем не менее до знакомства с SOA
> его никто не использовал.
Это, минимум, большая натяжка. Я помню, что этот термин вполне нормально
употреблялся в ФИДОшных флеймах еще в прошлом тысячелетии, причем еще до
изобретения XML.

То что менеджеры узнали этот термин только недавно — это еще ничего не
значит.

Здравствуйте, IT, Вы писали:

>>> Контракт как популярный термин был введён в SOA и обозначает формальное
>>> соглашение по взаимодействию между сервисами, независимое от платформ и
>>> языков программирования.
C>>Hint: термин "контракты" в Eiffel появился, эдак, в начале 90-х.

IT>В юриспруденции он появился ещё раньше. Тем не менее до знакомства с SOA его никто не использовал.

<занудство on>ну я использовал до своего личного знакомства с SOA, именно как выше в квоте определено, заменяя "сервисы" на "сущности"</занудство off>

Здравствуйте, Cyberax, Вы писали:

C>Это, минимум, большая натяжка. Я помню, что этот термин вполне нормально
C>употреблялся в ФИДОшных флеймах еще в прошлом тысячелетии, причем еще до
C>изобретения XML.

Может быть и использовался, но вот как-то не прижился.

C>То что менеджеры узнали этот термин только недавно — это еще ничего не значит.

Для тебя может и не значит, а я предпочитаю общаться с людьми на одном и том же языке и не устраивать терминологический трёп вроде этого по разным пустякам.

Здравствуйте, dottedmag, Вы писали:

IT>>В юриспруденции он появился ещё раньше. Тем не менее до знакомства с SOA его никто не использовал.

D><занудство on>ну я использовал до своего личного знакомства с SOA, именно как выше в квоте определено, заменяя "сервисы" на "сущности"</занудство off>

Я не возражаю против использования этого термина в любой интерпретации. Только сегодня для многих он тестно связан с SOA. Хорошо это или плохо мне всё равно. Если этот термин нам всем так нравится как замена многословного "публичный интерфейс", то для того, чтобы его узурпировать нужно как минимум приучить понимать его других в этом контексте. У меня лично он чётко ассоциируется с SOA. Хочешь поменять мои рефлексы, используй какое-то время пояснения вроде — контракт (публичный интерфейс модуля) бла-бла-бла. А пока не удивляйся при упоминании контрактов вопросам из серии "А при чём тут вообще SOA ".

Здравствуйте, Sinclair, Вы писали:

S>Типы в ФП тоже вряд ли будут себя вести "правильным" с точки зрения Барбары образом. Потому, что, к примеру, целое число нельзя заменить комплексным — извлечение корня из целой -1 даст совсем другой результат, чем из комплексной. Да и в обратную сторону тоже нельзя.

А между целыми и комплексными определены отношения супертип-подтип?

S>А если подойти с должной строгостью, то даже пытаться применить принцип подстановки к ним нельзя — в терминологии ФП экземпляры типов вовсе не имеют никакого поведения, стало быть и сравнивать нечего.

LSP ничего не говорит о собственном поведении типов. Он связан только с подстановками.

Здравствуйте, IT, Вы писали:

IT>Это всё, Гена, надо было говорить в своём первом сообщении

Автор: Геннадий Васильев
Дата: 28.12.06

. Тогда и вопросов бы не было.

Это сообщение было вообще на другую тему.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Геннадий Васильев, Вы писали:

IT>>>И как эта пробема решается другими средствами?

ГВ>>Я тебе должен рассказывать про наследование и фабрики? Игорь, я точно не с твоим двойником общаюсь?

B>Наверное имеется ввиду что во многих реальных и более примитивных случаев усложнение логики не окупается и бывает проще, выгоднее и нагляднее использовать switch или else if.

Как только дело доходит до множественной диспетчеризации (а собственно сама идеология паттерн-матчинга именно оттуда), ни ифы, ни фабрики с наследованием не спасают; ну или как минимум выразительность сильно страдает.

Здравствуйте, Cyberax, Вы писали:

C>То есть, контракты можно представить в виде набора аксиом. Для того же
C>sqrt у нас есть аксиома "sqrt(x)*sqrt(x)=x".

Согласись, что такой конктракт уже ничего общего с тем о чем говорил Ваня не имеет. В современных ЯП подобные контракты выражаются только ассертами. Кое что есть в Sepc#, Nemerle и совсем чуть-чуть в Эфиле (в том смысле, что проверки только в рантайме, а это почти те же ассерты). Причем такие контракты накладываются отнюдь не только на объекты. Они накладываются на функции/методы, циклы и т.п.

Здравствуйте, IT, Вы писали:


IT>В юриспруденции он появился ещё раньше. Тем не менее до знакомства с SOA его никто не использовал.

Я бы сказал, что со статистической точки зрения Eiffel вообще никто не использовал и не использует.

VladD2 wrote:
> C>То есть, контракты можно представить в виде набора аксиом. Для того же
> C>sqrt у нас есть аксиома "sqrt(x)*sqrt(x)=x".
> Согласись, что такой конктракт уже ничего общего с тем о чем говорил
> Ваня не имеет.
Да, согласен.

> В современных ЯП подобные контракты выражаются только
> ассертами. Кое что есть в Sepc#, Nemerle и совсем чуть-чуть в Эфиле (в
> том смысле, что проверки только в рантайме, а это почти те же ассерты).
> Причем такие контракты накладываются отнюдь не только на объекты. Они
> накладываются на функции/методы, циклы и т.п.
Именно. Хотя исследования в этом направлении идут — GNU Hurd будет
использовать bitC для создания доказанного микроядра.

Здравствуйте, Sinclair, Вы писали:

S>Иван, забей.
Я уже.. В принципе мысль моя наверное ясна, а терминологические споры на данный момент мне не очень интересны..

S> Эдак мы доберемся до двуединства Инь и Янь и их достаточности для описания всего сущего.
Заманчиво..

S> К сожалению, из такой безусловно справедливой модели не удастся извлечь ничего, мало-мальски практически пригодного.
Это уже другой вопрос.. )

Здравствуйте, IT, Вы писали:

IT> Как минимум я не буду это отражать на веб-сервисамы, SOA и WCF и мы сразу начнём говорить на одном языке
Так проблема была в том, что я назвал это "контракт"? Ок, слово "спецификация" тебя устроит? )

Здравствуйте, VladD2, Вы писали:

VD>Ты почитай внимательно обсуждение.

Контракты и интерефейсы тоже догмы той идиологии

Это кто-то другой за тебя писал?

VD> Я говорил о том, что применение данного принципа становится бессмысленным как только ты отходишь от приципов ООП
А я говорил, что нет, по пятому кругу пойдем?

VD> Иначе разговор не получится.
Да он и так не очень-то.