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

VD>>>В том, что или они все же не чисто функциональные, или значительно менее эффективны нежели их императивные аналоги.
PA>>Устроим шустрик?
VD>Можно. Быстрая сортировка устроит?
Драсьте ! Мы о чем говорили? О множествах, реализованных на сбалансированных деревьях.

На остальную часть твоего послания не отвечаю, сорри, что-то духу нет. Останемся при своем мнении.

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

LCR>>Рубишь с плеча, ажно щепки летят во все стороны Lambda-вычисления (и как следствия функциональные языки) — это раздел математики. Математика — точная наука.
V>Скорее, это единственный раздел, который УДАЛОСЬ хорошо формализовать. Опять же, за счет нескольких простых допущений, которые оказались верны для замыканий.
Т.е. как это — удалось, за счет каких допущений, каких замыканий? Лямбда-исчисление именно родилось для формализации оснований математики, затем было применено для исследования проблем вычислимости. Оказалось, что оно эквивалентно машинам Тьюринга. И только потом нашлись энтузиасты, которые на его базе построили языки программирования. А то, что анонимные функции в языках вроде Шарпа называют лямбда-функциями — не более, чем метафора.

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

VD>>>>В том, что или они все же не чисто функциональные, или значительно менее эффективны нежели их императивные аналоги.
PA>>>Устроим шустрик?
VD>>Можно. Быстрая сортировка устроит?
PA>Драсьте !

Привет.

PA> Мы о чем говорили? О множествах, реализованных на сбалансированных деревьях.

Я говорил, о том, что ФП не всегда обеспечивает сравнимой с императивным скорости выполнения. Реализация быстрой сортировки это прекрасно демонстрирует.

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

LCR>Согласен, пока не всегда... Приходится переходить к императивному способу.

Ну, вот и не нужно этого бояться. А посему нужно обеспечить удобный императивный синтаксис, чтобы люди не чувствовали дискомфорт от работы на императивном расширении.

LCR>Но есть и хорошие новости. Например, _гарантируется_, что хвостовая рекурсия свернётся в цикл.

Здорово. Это позволяет использовать рекурсию без боязни потерять в производительности. Не более того. Никаких других выводов из этого сделать нельзя. Рекурсия не отрицает модификации памяти.

LCR>Кроме того, у функциональщиков с опытом приходят навыки сведения многих алгоритмов к виду, гарантирующему оптимизацию, и поэтому код хорошего функционального программиста по эффективности не хуже императивного.

Это снова пошла реклама. Оптимизацией пусть занимается компилятор. А вот я могу обеспечить алгоритмическую эффективность и не хочу жертвоать ею ради соблюдения стиля.

Более того. Я не считаю ту же рекурсию приципиально более декларативной нежели циклы. К примеру, конструкция foreach зачастую выглядит куда более понятно нежели концевая рекурсия. И по фигу мне, что внутри переменная модифицируется. Как ты правильно подметил, компилятор тоже порой переписыват код так, что он начинает модифицировать переменные. Ничего страшного в этом нет.

Апологеты ФЯ слишком сильно переоценивают влияние немодифицируемости переменных в общем надежности программы.

LCR>У императивщиков таких навыков нет, зато есть множество навыков, скажем, по ограничению влияния побочных эффектов (почему глобальные переменные плохой тон?, почему нужна инкапсуляция?).

Инкапсуляция есть инкапсуляция. Она нужна для выражения абстракции.

LCR>Короче, они друг друга никогда не поймут

Если они догматики, то конечно. А так... нет проблем.

VD>>Между тем, если состояние нужно, то нет смысла с ним боросться.
LCR>Да, конечно.

Ну, а тогда румно забить на догмы и брать лучше из всех парадигм. Если вычисления хорошо укладываются в выражения, то использовать ФС, если надо эмулировать объекты, использовать ОО-стиль с модификацией состояния. Тогда и сам предмет спора уйдет.

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

V>>Знаешь, пока ЮАЙщикам на дотнет рановато, ей-богу.

IT>Интересно, и чем я на прошлом проекте в Banc Of America Securities занимался?

Тем же чем и я в Филипсе на прошлом. Применял сырой и кривой в реализации инструмент. Дотнет-бинд на ГУИ от MS на ее собственные нативные вынь-контролы выполнен бездарно. Реальные тормоза в ГУИ не от особенностей VM.Net, а от необоснованных синхронизаций на каждый чих, от путанной системы взаимоотношений ГУИ-элементов и данных, отображаемых ими. От тормознутой и прожорливой реализации системы embedded-ресурсов, от полнейшей "глупости" системы локализации в Windows.Forms, которые в сочетании с тормознутым менеджером ресурсов дают потрясающий "кумулятивный эффект", на который обращают внимание многие, пользуясь ГУИ, нарисованным в дотнете. Я уже где-то здесь говорил, что субъективно ГУИ на дотнете работает примерно с той же скоростью, что и нативные приложения на каком-нить пне 150-200МГц максимум, т.е. аналогично технике 8-ми летней давности.

Изучение внутренностей виндоуз-форм наводит на мысль, что все это имело примерно такой приоритет во время разработки: "лишь бы было", т.е. похоже, что их интересовал сам факт работоспособности, а не технические показатели разработанного бинда.

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

VD>В общем, неплохо было бы ввести нечто вроде внешних интерфейсов и "особенностей". Первый должны являться чем-то похожим на концепты из будущего стандарта плюсов, а вторые это подключение реализации. Ведь как было бы здорво сделать нечто вроде:
VD>[c#]
VD>interface IAdd<T>
VD>{
VD> T Add(T other);
VD>}

[поскипан код]

для того, что ты хочешь надо вводить констрейны для дженериков не на основе интерфейсов, а на основе неких контрактов. Тогда можно было бы требовать не реализации интерфейса, а наличия, например, перегруженных операторов +, -, *, / и т.д.

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

V>Тем же чем и я в Филипсе на прошлом. Применял сырой и кривой в реализации инструмент. Дотнет-бинд на ГУИ от MS на ее собственные нативные вынь-контролы выполнен бездарно.

Баиндинг после обработки напильником вполне работоспособная вещь. Что касается нативных контролов, то с этим хуже. Я бы даже сказал — плохо. Совсем.

V>Изучение внутренностей виндоуз-форм наводит на мысль, что все это имело примерно такой приоритет во время разработки: "лишь бы было", т.е. похоже, что их интересовал сам факт работоспособности, а не технические показатели разработанного бинда.

Не удивлюсь, если это так. С другой стороны, Джаве понадобилось 10 лет, что обзавестись более менее приличными гуями. Дотнет вышел только 2.0. Кстати, надо глянуть что там с гуями. По идее должно быть побыстрее.

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

IT>Не удивлюсь, если это так. С другой стороны, Джаве понадобилось 10 лет, что обзавестись более менее приличными гуями. Дотнет вышел только 2.0. Кстати, надо глянуть что там с гуями. По идее должно быть побыстрее.

Поздравляю Вас, господин соврамши.

Если не ошибаюсь — Джава появилась (стала доступной публике) в 95-м году. А Swing (JFC) появился 98-м году. В 99-м году вошел в состав JDK 1.2
Далее. SWT появился где-то в 2000-м году. Он изначальна был быстрый.

Так что насчет 10 лет — это все неправда. Насчет скорострельности — ерунда. На JDK 1.3 все уже летало. Конечно, на пне-200 это все будет тормозить, но на PIII-600 уже все абсолютно без проблем. Естественно, если памяти хватает, все-таки управляемая среда.

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

IT>>Не удивлюсь, если это так. С другой стороны, Джаве понадобилось 10 лет, что обзавестись более менее приличными гуями. Дотнет вышел только 2.0. Кстати, надо глянуть что там с гуями. По идее должно быть побыстрее.

_>Поздравляю Вас, господин соврамши.

Вот сейчас возьму и забаню

_>Если не ошибаюсь — Джава появилась (стала доступной публике) в 95-м году. А Swing (JFC) появился 98-м году. В 99-м году вошел в состав JDK 1.2
_>Далее. SWT появился где-то в 2000-м году. Он изначальна был быстрый.

Свин? Быстрый? Введите Вия! (ну тут типа прыгает нечисть с бубнами и чуваку открывают консервные банки)

_>Так что насчет 10 лет — это все неправда. Насчет скорострельности — ерунда. На JDK 1.3 все уже летало. Конечно, на пне-200 это все будет тормозить, но на PIII-600 уже все абсолютно без проблем. Естественно, если памяти хватает, все-таки управляемая среда.

Осталось только доставить в зал самого обвиняемого

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

IT>Вот сейчас возьму и забаню

Что-то ты так эмоцонально среагировал ))). Не бери в голову, просто факты проверяй и все.

IT>Свин? Быстрый? Введите Вия! (ну тут типа прыгает нечисть с бубнами и чуваку открывают консервные банки)

Быстрый. Я считаю, что быстрый. Медленнее, конечно, чем WinAPI, но все-таки. То есть рисование не является тормозом. Тормоза обычно идут в другом месте. Поэтому я и говорю — быстрый.

_>>Так что насчет 10 лет — это все неправда. Насчет скорострельности — ерунда. На JDK 1.3 все уже летало. Конечно, на пне-200 это все будет тормозить, но на PIII-600 уже все абсолютно без проблем. Естественно, если памяти хватает, все-таки управляемая среда.

IT>Осталось только доставить в зал самого обвиняемого

Кого ты предлагаешь в роли обвиняемого? )))

Здравствуйте, vdimas, Вы писали:
V>для того, что ты хочешь надо вводить констрейны для дженериков не на основе интерфейсов, а на основе неких контрактов. Тогда можно было бы требовать не реализации интерфейса, а наличия, например, перегруженных операторов +, -, *, / и т.д.
Нет. Для того, что он хочет, нужно выбросить идею со статическими мемберами для операторов на помойку истории, и перейти к системе арифметических интерфейсов. См. напр. object.Equals(object, object), object.Equals(object), IEquatable<T> и пр.
Реализация новых типов констреинтов чревата большим геморроем на уровне джита, и не дает никаких преимуществ по сравнению с предлагаемой схемой.

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

S>Здравствуйте, vdimas, Вы писали:
V>>для того, что ты хочешь надо вводить констрейны для дженериков не на основе интерфейсов, а на основе неких контрактов. Тогда можно было бы требовать не реализации интерфейса, а наличия, например, перегруженных операторов +, -, *, / и т.д.
S>Нет. Для того, что он хочет, нужно выбросить идею со статическими мемберами для операторов на помойку истории, и перейти к системе арифметических интерфейсов.

Согласен только лишь с замечанием насчет статичности операторов — неудобно ИМХО

S>Реализация новых типов констреинтов чревата большим геморроем на уровне джита, и не дает никаких преимуществ по сравнению с предлагаемой схемой.

Очень даже дает преимущества. Тебе не нужно будет вводить новые интерфейсы и соответственно их имплементацию в типах там, где реально нужен лишь контракт на сигнатуры. А геморрой на уровне джита УЖЕ решен, ведь для value-типов производится вызов constrain-методов БЕЗ боксинга. О чем это говорит? Налицо факт, что для value-типов интерфейсы в constrain используются именно как контракты на сигнатуры, а не как базовая сущность и джит прекрасно разруливает этот момент. А то, что реально эти value-типы сейчас обязаны реализовать указанные в constrain интерфейсы — не более чем ненужный побочный эффект. Реально-то интерфейсы в подобных моментах не используются по прямому назначению (для организации "бинарной совместимости" то бишь).

Здравствуйте, vdimas, Вы писали:
V>Очень даже дает преимущества. Тебе не нужно будет вводить новые интерфейсы и соответственно их имплементацию в типах там, где реально нужен лишь контракт на сигнатуры.
Термин "реально" в данном контексте мне вообще непонятен. Кроме того, мне непонятно, почему ты считаешь, что "контракт на сигнатуры" лучше интерфейса. С учетом того, что интерфеёс и есть контракт на сигнатуры.
V> А геморрой на уровне джита УЖЕ решен, ведь для value-типов производится вызов constrain-методов БЕЗ боксинга. О чем это говорит? Налицо факт, что для value-типов интерфейсы в constrain используются именно как контракты на сигнатуры, а не как базовая сущность и джит прекрасно разруливает этот момент.
Нет. Налицо факт, что джит просто оптимизирует боксинг там, где видит точный тип.
V>А то, что реально эти value-типы сейчас обязаны реализовать указанные в constrain интерфейсы — не более чем ненужный побочный эффект. Реально-то интерфейсы в подобных моментах не используются по прямому назначению (для организации "бинарной совместимости" то бишь).
Используются, и еще как. Ты пойми, что сам по себе констреинт — это всего лишь побочный эффект от встраивания сигнатуры вызова в MSIL. Пока что MSIL не позволяет вставить запись "вызови мне какой-нибудь метод с вот такой сигнатурой". Джит не занимается биндингом сигнатур; это делает компилятор. Именно компилятору нужен констреинт — чтобы он понял, какой metodref складывать в MSIL. Перевод операторов на интерфейсы позволяет обойтись тем же ядром фреймворка, без его переработки.

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

S>Здравствуйте, vdimas, Вы писали:
V>>Очень даже дает преимущества. Тебе не нужно будет вводить новые интерфейсы и соответственно их имплементацию в типах там, где реально нужен лишь контракт на сигнатуры.
S>Термин "реально" в данном контексте мне вообще непонятен. Кроме того, мне непонятно, почему ты считаешь, что "контракт на сигнатуры" лучше интерфейса. С учетом того, что интерфеёс и есть контракт на сигнатуры.

Интерфейс — это еще и бинарная совместимость, и приведения типов и т.д. Зачастую это все не нужно, особенно в паттернах "template method".

V>> А геморрой на уровне джита УЖЕ решен, ведь для value-типов производится вызов constrain-методов БЕЗ боксинга. О чем это говорит? Налицо факт, что для value-типов интерфейсы в constrain используются именно как контракты на сигнатуры, а не как базовая сущность и джит прекрасно разруливает этот момент.
S>Нет. Налицо факт, что джит просто оптимизирует боксинг там, где видит точный тип.

Ну? Осталось совсем чуть-чуть чтобы сделать вывод... С помощью чего у него это выходит?

V>>А то, что реально эти value-типы сейчас обязаны реализовать указанные в constrain интерфейсы — не более чем ненужный побочный эффект. Реально-то интерфейсы в подобных моментах не используются по прямому назначению (для организации "бинарной совместимости" то бишь).
S>Используются, и еще как. Ты пойми, что сам по себе констреинт — это всего лишь побочный эффект от встраивания сигнатуры вызова в MSIL. Пока что MSIL не позволяет вставить запись "вызови мне какой-нибудь метод с вот такой сигнатурой". Джит не занимается биндингом сигнатур; это делает компилятор. Именно компилятору нужен констреинт — чтобы он понял, какой metodref складывать в MSIL. Перевод операторов на интерфейсы позволяет обойтись тем же ядром фреймворка, без его переработки.

Да знаю я как оно работает и на переработку ядра и намекаю. А на самом деле в MSIL можно вложить произвольный methodref уже сейчас (т.е. несуществующего метода несуществующего типа несуществующей сборки).

Здравствуйте, vdimas, Вы писали:
V>Интерфейс — это еще и бинарная совместимость, и приведения типов и т.д. Зачастую это все не нужно, особенно в паттернах "template method".
Да-да-да, но нас интересует исключительно ценный мех.
V>Ну? Осталось совсем чуть-чуть чтобы сделать вывод... С помощью чего у него это выходит?
Вот тут уж я не знаю. Наверное, с помощью некоторого анализа.
V>Да знаю я как оно работает и на переработку ядра и намекаю.
А я не вижу смысла вносить в ядро функциональность, которую можно реализовать на более высоком уровне. Ну вот объясни мне, зачем это делать? Ну кроме как "шоб було"?
V>А на самом деле в MSIL можно вложить произвольный methodref уже сейчас (т.е. несуществующего метода несуществующего типа несуществующей сборки).
Задачи вложить несуществующий metodref не стоит. Стоит задача положить референс на метод фактического типа генерик параметра, который имеет некоторую фиксированную сигнатуру. На том уровне заблуждений, который я сейчас имею, я не вижу способа это сделать, оставаясь в рамках существующей модели.

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

V>>Ну? Осталось совсем чуть-чуть чтобы сделать вывод... С помощью чего у него это выходит?
S>Вот тут уж я не знаю. Наверное, с помощью некоторого анализа.

С помощью отказа от "бинарной" совместимости. т.е. механизм у нас уже как бы есть и геммороя никакого не будет. Осталось приделать интерфейс к этому механизму в виде доп. сущностей VM.Net (напомню, речь об отказе от приведения к интерфейсам, т.е. от боксирования для value-типов)

V>>Да знаю я как оно работает и на переработку ядра и намекаю.
S>А я не вижу смысла вносить в ядро функциональность, которую можно реализовать на более высоком уровне. Ну вот объясни мне, зачем это делать? Ну кроме как "шоб було"?

Потому как уже существующие типы способны удовлетворять миллионам комбинаций из различных контрактов, даже тех, о которых не имели представление в момент компиляции. А в случае работы через интерфейсы... в общем ты понял.

Понимаешь, сейчас на интерфейсы взвалено слишком много "обязанностей":
— декларация контрактов (по сути, это должна быть единственная их функциональность)
— бинарная совместимость контрактов... этот момент уже идет из особенностей реализации полиморфизма в семействе таких технологий как С++/Дельфи/Java/.Net. Например в SmallTalk такая проблема не стоит.

Я вижу лишь удобства, если явно разделить эти сущности. Ключевое слово "interface" вполне можно оставить для обозначения "бинарной совместимости", типа как стандарты на аппаратные разъемы тоже называются интерфейсами, а вот то первое обозвать "contract" или там "agreement".

Будут ли проблемы с синтаксисом? Да никогда:

contract Iterator<T> {
    T Current { get; }
    bool MoveNext();
}

interface IEnumerator<T> : Iterator<T> {
    void Reset();
}

Добавить в допустимую цепочку наследования еще 1 элемент:
контракты -> интерфейсы -> классы.

Ограничения в дженериках допустить по интерфейсам и контрактам.

V>>А на самом деле в MSIL можно вложить произвольный methodref уже сейчас (т.е. несуществующего метода несуществующего типа несуществующей сборки).
S>Задачи вложить несуществующий metodref не стоит. Стоит задача положить референс на метод фактического типа генерик параметра, который имеет некоторую фиксированную сигнатуру. На том уровне заблуждений, который я сейчас имею, я не вижу способа это сделать, оставаясь в рамках существующей модели.

Оставаясь в рамках стандартного Emit, ты хотел сказать. Формат сборок ничего не запрещает, и это все даже сможет подниматься джитом, если у интересующего типа есть нужный метод с нужной сигнатурой. Надо просто расширить Emit, или написать свой аналогичный тул

Здравствуйте, vdimas, Вы писали:
V>С помощью отказа от "бинарной" совместимости. т.е. механизм у нас уже как бы есть и геммороя никакого не будет. Осталось приделать интерфейс к этому механизму в виде доп. сущностей VM.Net (напомню, речь об отказе от приведения к интерфейсам, т.е. от боксирования для value-типов)
Я перестаю следить за твоей мыслью. Я не очень хорошо знаю, как именно реализуются интерфейсы в структах — может быть, там действительно формируется некоторая VMT, содержащая переходники для вызова "настоящих" методов на забоксенных данных. В таком случае, джит при параметризации дженерика структом действительно хитрит и "срезает угол", хотя я не вижу никакой проблемы делать то же самое вообще во всех случаях, когда точно известен тип:

int i = 5;
IComparable ii = i; // боксинг
if (ii.CompareTo(4))  
{
...

Здесь теоретически джит может проследить за тем, что а) точный тип ii известен и б) он не используется ни для чего, кроме вызова метода в локальном контексте. Т.е. можно выкинуть боксинг как избыточный. Я не в курсе, делает ли так современный джит.
V>Потому как уже существующие типы способны удовлетворять миллионам комбинаций из различных контрактов, даже тех, о которых не имели представление в момент компиляции. А в случае работы через интерфейсы... в общем ты понял.
Нет, не понял. В случае работы через интерфейсы мы имеем массу дополнительных гарантий. Дак-тайпинг — может и хорошая штука, но у него есть масса недостатков. И всовывать его в дотнет я считаю идеологически неверным.

V>Я вижу лишь удобства, если явно разделить эти сущности. Ключевое слово "interface" вполне можно оставить для обозначения "бинарной совместимости", типа как стандарты на аппаратные разъемы тоже называются интерфейсами, а вот то первое обозвать "contract" или там "agreement".
В дотнете бинарная совместимость и гарантии эквивалентны. Не вижу повода отказываться от этой эквивалентности.

V>Будут ли проблемы с синтаксисом? Да никогда:
V>[c#]
V>contract Iterator<T> {
V> T Current { get; }
V> bool MoveNext();
V>}
Вопрос в том, как это проверять.
V>Оставаясь в рамках стандартного Emit, ты хотел сказать. Формат сборок ничего не запрещает, и это все даже сможет подниматься джитом, если у интересующего типа есть нужный метод с нужной сигнатурой. Надо просто расширить Emit, или написать свой аналогичный тул
дело не в емите. Дело в самом MSIL. Существующий формат байт-кода не позволяет делать такие трюки. И не будет позволять, потому что иначе он не пройдет верификацию.
Или я чего-то фатально не понимаю? Ты не мог бы привести пример байт-кода для вызова статического метода op_addition на типе T, где оба аргумента тоже имеют тип Т?

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

S>Я перестаю следить за твоей мыслью. Я не очень хорошо знаю, как именно реализуются интерфейсы в структах — может быть, там действительно формируется некоторая VMT, содержащая переходники для вызова "настоящих" методов на забоксенных данных.

Забоксенный value-type — это и есть экземпляр "настоящего" класса, т.е. это именно тот вариант представления типа, как если бы мы описывали этот тип как reference-type (со ссылкой на тип). Небоксированный value-type — это просто кусок памяти размером, достаточным для вмещения полей, безо-всяких vtable.

Я лишь напирал на тот факт, что джит на настоящий момент уже в состоянии трактовать интерфейсы как контракты (например, для value-type), а не как бинарные "разъемы". Т.е., по-сути, механизм обслуживания контрактов уже готов.

V>>Потому как уже существующие типы способны удовлетворять миллионам комбинаций из различных контрактов, даже тех, о которых не имели представление в момент компиляции. А в случае работы через интерфейсы... в общем ты понял.

S>Нет, не понял. В случае работы через интерфейсы мы имеем массу дополнительных гарантий.

Ммм... каких дополнительных гарантий? Что-то не вспомню ни одной, кроме бинарной совместимости с другими такими же интерфейсами. Только вот незадача — в большинстве случаев, когда интерфесы используются как констрейны в дженериках, эти интерфейсы НЕ ИСПОЛЬЗУЮТСЯ по прямому назначению. Т.е. никто не юзает их в непосредственном виде ВНЕ дженерика. Ну и нафига тогда нам это дополнительное ограничение в виду обязательности НАСЛЕДОВАНИЯ интерфейса (щаз AVK возмутится по поводу "наследования", но в сравнении с обсуждаемыми контрактами этот термин точнее отражает суть использования интерфейсов в данный момент)

S>Дак-тайпинг — может и хорошая штука, но у него есть масса недостатков. И всовывать его в дотнет я считаю идеологически неверным.

Это не дак-тайпинг, это, считай, дробление размерности интерфейсов до единичных методов... илиже до произвольных комбинаций этих методов. По крайней мере, в отличие от дак-тайпинга ты сохраняешь в целостности и сохранности типизированность и строгую статическую структуру.

Ты выбери для обзора другой угол. Логически, интерфейсы — это и есть constrain (или контракт, и так и так верно). Все остальные их св-ва в дотнете обусловлены особенностями реализации полиморфизма. Я лишь предлагаю сделать возможным задавать контракты (или ограничения) БЕЗ завязки на инструмент полиморфизма. Т.е. пока что я вижу применение контрактов только в ограничениях дженериков.

Вся штука в том, что для того, чтобы тип удовлетворял конракту, он не обязан от него наследоваться. Таким образом, я верну себе львиную долю гибкости от шаблонных решений (которую имел на С++).


V>>Я вижу лишь удобства, если явно разделить эти сущности. Ключевое слово "interface" вполне можно оставить для обозначения "бинарной совместимости", типа как стандарты на аппаратные разъемы тоже называются интерфейсами, а вот то первое обозвать "contract" или там "agreement".
S>В дотнете бинарная совместимость и гарантии эквивалентны.

Угу, подобная эквивалентность — это принятие побочных эффектов за целевые.


По поводу того, как в MSIL сейчас сохраняются дженерики — дык это какая-то недоработка... Недодумали они чего-то.

Вот пример, который не компилится:

    public interface I1 {
        void M1();
        void M2();
    }

    public interface I2 {
        void M2();
        void M3();
    }

    public class Class1<T> where T:I1, I2 {
        T _field;

        void MM() { _field.M2();  }
    }

Казалось бы, все вполне логично с т.з. проектирования абстракций. Только не компилится... и вот только попробуй мне сказать, что ситуацию в этом примере спасет явное приведение к одному из интерфейсов... какое нафиг может быть преобразование типа к ограничению???!!!

"Чистые" контракты могли бы быть лишены всеего этого багажа непродумманости.
Более того, над контрактами можно было бы выполнять операции как над множествами: объединять, вычитать, находить разность и т.д. Результатом подобных операций был бы новый контракт.

vdimas,

V>По поводу того, как в MSIL сейчас сохраняются дженерики — дык это какая-то недоработка... Недодумали они чего-то.

V>Вот пример, который не компилится:
V>

V>    public interface I1 {
V>        void M1();
V>        void M2();
V>    }

V>    public interface I2 {
V>        void M2();
V>        void M3();
V>    }

V>    public class Class1<T> where T:I1, I2 {
V>        T _field;

V>        void MM() { _field.M2();  }
V>    }
V>

Вопросик можно? Спасибо.

Можно ввести общий интерфейс I содержащий только M2 и параметризовать класс им.

Что может помешать?
Ситуация, когда интерфейсы заморожены (нельзя или невозможно поменять), довольно редкая.
Комбинаторный "взрыв" количества интерфейсов. Тоже весьма специфический случай.
Какие ещё случаи я забыл?

Кроме того, то, что указанный вызов не кушается компилятором, это не слишком большая проблема. Получается просто некрасиво, но не более того (могло бы быть сгенерировано компилятором).

                ...
                void MM()
                {
                    _f1 = _field as I1;
                    _f2 = _field as I2;
                    if (_f1 != null)
                        _f1.M2()
                    else
                        _f2.M2();
                }

V>"Чистые" контракты могли бы быть лишены всеего этого багажа непродумманости.
V>Более того, над контрактами можно было бы выполнять операции как над множествами: объединять, вычитать, находить разность и т.д. Результатом подобных операций был бы новый контракт.

Я продолжу. Контракты потом захочется организовывать в коллекции, чтобы автоматизировать вещи типа $\Cup_i C_i$. Затем захочется делать выборку из этих коллекций. Чтобы делать выборку, нужна нотация для описания условий. И т.д. и т.п.

Уже целый язык получается (на ум приходят аналогии с xpath и sql).

Картина получается слишком сложной, имхо.

Уфф...

V>>"Чистые" контракты могли бы быть лишены всеего этого багажа непродумманости.
V>>Более того, над контрактами можно было бы выполнять операции как над множествами: объединять, вычитать, находить разность и т.д. Результатом подобных операций был бы новый контракт.

LCR>Я продолжу. Контракты потом захочется организовывать в коллекции, чтобы автоматизировать вещи типа $\Cup_i C_i$. Затем захочется делать выборку из этих коллекций. Чтобы делать выборку, нужна нотация для описания условий. И т.д. и т.п.

LCR>Уже целый язык получается (на ум приходят аналогии с xpath и sql).

LCR>Картина получается слишком сложной, имхо.

Тут мой стиль изложения хромает, выражусь точнее:
Существование контрактов => язык операций над ними => слишком сложно.