Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

Цитата DesweR @ 02.11.11, 08:21

Только вот как?

А как ещё?

Цитата Flex Ferrum @ 02.11.11, 08:19

Я интерфейсом считаю фиксацию некоторого поведение. Контракт между классом и его клиентами. Поведение - это набор методов.

Цитата Flex Ferrum @ 02.11.11, 08:19

Если это семантически разные методы, об этом должно быть явным образом сообщено клиенту.

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

Цитата D_KEY @ 02.11.11, 08:17

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

Тот самый явный каст?

Цитата MyNameIsIgor @ 02.11.11, 08:28

А не кажется, что взаимоисключающие параграфы? Набор методов отражает поведение или всё же оно не зависит от их сигнатур?

Нет. Потому что сигнатура метода - это тоже часть контракта. Два набора одноимённых методов, но с разными сигнатурами, будут фиксировать разное поведение.

Цитата MyNameIsIgor @ 02.11.11, 08:28

Цитата D_KEY @ 02.11.11, 08:17

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

Тот самый явный каст?

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

Цитата DesweR @ 02.11.11, 02:26

Самое элементарное - фабрика.

И что, по твоему вот это:

  A := Factory.Get<IA>;
  B := Factory.Get<IB>;

IA, IB - Интерфейсы не известные на этапе компиляции? Гхм... Боюсь спросить, а как ты с ними дальше работаешь, если ты не знаешь что получил?

Цитата MyNameIsIgor @ 02.11.11, 08:28

Набор методов отражает поведение или всё же оно не зависит от их сигнатур?
В том то и проблема, что пока семантика пишется в документации для людей, а не в коде для компилятора, набор методов - это набор методов, а не поведение.

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

Цитата Flex Ferrum @ 02.11.11, 08:32

Нет. Потому что сигнатура метода - это тоже часть контракта.

Но не весь. Возвращаясь к тому же стеку, если я не буду использовать top, то благополучно смогу запихнуть очередь. Ну, и что я получу, сделав push, а потом pop?

Цитата Flex Ferrum @ 02.11.11, 08:32

Два набора одноимённых методов, но с разными сигнатурами, будут фиксировать разное поведение.

Ок. Вопрос в том, что будут делать два одноимённых метода с одинаковыми сигнатурами. Кто тут мамой поклянётся, что они ведут себя одинаково?

Цитата MyNameIsIgor @ 02.11.11, 08:35

Но не весь. Возвращаясь к тому же стеку, если я не буду использовать top, то благополучно смогу запихнуть очередь. Ну, и что я получу, сделав push, а потом pop?

Цитата MyNameIsIgor @ 02.11.11, 08:35

Ок. Вопрос в том, что будут делать два одноимённых метода с одинаковыми сигнатурами. Кто тут мамой поклянётся, что они ведут себя одинаково?

Ну, тут ты прав.

Цитата D_KEY @ 02.11.11, 08:35

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

Да, они Ъ-вещь. Но даже они не могут всё описать.
Ты пойми, мои претензии гораздо более идеологические, чем практические. И я отдаю себе в этом отчёт. Ну, просто если в Go утки-интерфейсы выглядят идеологически цельно, то когда мы захотим такие же в плюсах с их шаблонами, множественным наследованием и абстрактными классами, то что мы получим? Уже озвученную автоматизацию написания наследника? И вместе с ней потенциальные проблемы а-ля auto_ptr. Мой вопрос прост: а все уверены, что это нужно?

Цитата DesweR @ 02.11.11, 02:26

Если кто забыл, TBC1 и TBC2 реализуют только интерфейсы IB и IC, указанные явно в декларации, но никак не интерфейс IA, несмотря даже на то, что он является их базовым.

А если в IA будет метод, который не реализован классами TBC1 и TBC2, он ведь будет виден? Думаю будет, и если мы его вызовем, думая что он таки реализован в производных классах, что мы получим то? pure virtual function call ?

Цитата MyNameIsIgor @ 02.11.11, 08:43

Но даже они не могут всё описать.

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

Цитата Flex Ferrum @ 02.11.11, 08:22

А как ещё?

Явным указанием в декларации класса, что он реализует именно этот интерфейс, а не какие угодно со аналогичной сигнатурой.

Цитата scorpion @ 02.11.11, 08:34

IA, IB - Интерфейсы не известные на этапе компиляции? Гхм... Боюсь спросить, а как ты с ними дальше работаешь, если ты не знаешь что получил?

Они не известны фабрике, ей это вообще по барабану.

Цитата scorpion @ 02.11.11, 08:45

А если в IA будет метод, который не реализован классами TBC1 и TBC2, он ведь будет виден?

Это не будет компилироваться, все методы интерфейса должны быть реализованы.

Сообщение отредактировано: DesweR - 02.11.11, 09:07

Цитата D_KEY @ 02.11.11, 08:48

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

Ну, а если допустить, что осуществимо хотя бы в большинстве случаев? Т.е. тогда мы имеем описание семантики для интерфейса-утки и двух классов, вроде как реализующими данный интерфейс (пусть будет стек и очередь). Здесь у меня вопрос: на сколько сложна реализация компилятора, сравнивающая эти описания и ещё при компиляции отвергающая очередь как не предоставляющего гарантию получения pop'ом того же элемента, что мы только что за'push'или?

Сообщение отредактировано: MyNameIsIgor - 02.11.11, 09:11

Цитата MyNameIsIgor @ 02.11.11, 09:10

Здесь у меня вопрос: на сколько сложна реализация компилятора, сравнивающая эти описания и ещё при компиляции отвергающая очередь как не предоставляющего гарантию получения pop'ом того же элемента, что мы только что за'push'или?

Для этого достаточно сопоставить инвариантов класса и интерфейса, а также пред- и пост- условия соответствующих методов.

Цитата D_KEY @ 02.11.11, 09:16

Для этого достаточно сопоставить инвариантов класса и интерфейса, а также пред- и пост- условия соответствующих методов.

Я понимаю. Просто они могут быть описаны по-разному

Добавлено 02.11.11, 09:21
Как вообще описать, что если я сделаю pop после push, то получу вставленный элемент?