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

Цитата DesweR @ 02.11.11, 09:07

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

Так причем тут фабрика, если ты пишешь:

Цитата DesweR @ 01.11.11, 09:38

В догонку тебе, запроси интерфейс, неизвестный на этапе компиляции, у объекта, тоже неизвестного на этапе компиляции.

Это как понять? Я понимаю буквально, т.е. запрашиваю интерфейс, о котором мне неизвестно ничего, и начинаю с ним работать. На С++, такое можно попытатся сделать с помощью шаблонов, и то, оно будет известно на этапе компиляции, ибо толку нет работать с какими то данными, о которых представления не имеешь. А на делфи, у тебя даже метод:

function  Get<T>: IInterface;

Возвращает вполне известный интерфейс IInterface .
Ты прежде чем писать такое, подумай что пишешь, иначе ты попросту вводишь людей в заблуждение.

Цитата DesweR @ 02.11.11, 09:07

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

Так ведь ты сам сказал, что :

Цитата

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

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

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

Дьявол кроется в деталях, а допустима ли будет утиная типизация, если у класса часть "реализованных" (аналогичных по сигнатуре) методов будет в приватной секции?

Цитата DesweR @ 02.11.11, 09:24

Дьявол кроется в деталях, а допустима ли будет утиная типизация, если у класса часть "реализованных" (аналогичных по сигнатуре) методов будет в приватной секции?

Нет, не допустима.

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

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

Математически? С помощью инварианта: top(push(s, x)) = x

Цитата scorpion @ 02.11.11, 09:23

Это как понять? Я понимаю буквально, т.е. запрашиваю интерфейс, о котором мне неизвестно ничего, и начинаю с ним работать.

Буквально не надо, естественно ты знаешь какие конкретные реализации регистрируешь и какие конкретные интерфейсы запрашиваешь, но самой фабрике заранее это неизвестно.

Цитата scorpion @ 02.11.11, 09:23

Возвращает вполне известный интерфейс IInterface.

Известный? Это базовый интерфейс, возвращается то - что запросили (либо не возвращается).
Корректнее так то так:

function  Get<T: IInterface>: T;

Цитата scorpion @ 02.11.11, 09:23

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

Всё правильно, реализуются явно указанные интерфейсы, такова идеология COM.
Пол года назад уже был разговор:

Цитата

Это отчасти вытекает из идеологии COM'а, интерфейс - это абстрактный протокол, который описывает только взаимодействие с объектом и не содержит детали его реализации. Возьмём класс X, реализующий некоторый функционал, класс X могут наследовать несколько других классов XA, XB, XC, в этом случае они наследуют и расширяют функционал родительского класса X, но никак его не замещают и не ограничивают, работает принцип подстановки Лисков, мы можем создать объект любого из дочерних классов, привести его к базовому и спокойно работать. Теперь возьмём интерфейс Y, описывающий некоторый абстрактный протокол, этот интерфейс могут реализовывать несколько классов YA, YB, YC, в этом случае они "наследуют" и реализовывают протокол взаимодействия и т.к. никакой базовой реализации у интерфейса нет - YA, YB, YC реализовывают протокол взаимодействия полностью сами, при этом теперь никем не гарантируется, что будет работать принцип подстановки Лисков, даже несмотря на схожесть сигнатур интерфейса, семантика его реализаций может быть различной (собственно в COM даже рекомендуется давать наименования методам с неопределённым смыслом, чтобы каждая реализация интерфейса могла их интерпретировать по своему). Тоже самое касается и наследования интерфейсов, должен соблюдаться не только сигнатурный контракт, но и гарантированно семантический, а для этого класс A, должен содержать реализацию интерфейсов и child и parent.

Добавлено 02.11.11, 09:52

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

Нет, не допустима.

В таком случае все варианты, когда реализация должна быть скрыта в классе, идут лесом. Оно вообще тогда надо?

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

Цитата DesweR @ 02.11.11, 09:48

Всё правильно, реализуются явно указанные интерфейсы, такова идеология COM.
Пол года назад уже был разговор:

Ну и там же явно сказано:

Цитата DesweR @ 02.11.11, 09:48

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

Цитата DesweR @ 02.11.11, 09:48

В таком случае все варианты, когда реализация должна быть скрыта в классе, идут лесом. Оно вообще тогда надо?

Не понял...

Цитата DesweR @ 02.11.11, 09:48

В таком случае все варианты, когда реализация должна быть скрыта в классе, идут лесом. Оно вообще тогда надо?

ты что-то путаешь. объясни, что ты имеешь в виду.

DesweR, это подправление здорово изменило отношения классов. Это ли не редизайн? Интересно будет послушать твоего коллегу, который после такой небольшой подправки получит у себя поведение, описываемое Flex Ferrum-ом.

Цитата Flex Ferrum @ 02.11.11, 07:12

Тут всё не так просто.

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

Цитата Flex Ferrum @ 02.11.11, 07:12

На duck typing весь статический полиморфизм в плюсах работает.

К сожалению. Но если есть альтернатива, то выбор ИМХО однозначен.

Цитата Romkin @ 02.11.11, 07:30

Утрируешь. На интерфейсах давно подобное делалось, подключаемые реализации.

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

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

А как ещё?

Что значит, как? Конечно же явным указанием отношениями между интерфесом и его реализацей.

Цитата Romkin @ 02.11.11, 07:30

Так же как и везде, компилируются. Иначе они не нужны, есть RTTI.

Это я понимаю. Потому и спрашиваю. Вон, DesweR рассказывает, как неизвестный при компиляции <T> может быть в run-time получен от неизвестного при компиляции объекта, и тем самым запросто заюзан неизвестный при компиляции интерфейс. Что-то не вяжется.

Цитата Qraizer @ 02.11.11, 15:28

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

Обычно на интерфейсах делают что-то вроде плагинов как раз. Это подразумевает именно подключаемую в процессе сборки объекта конкретную реализацию

Цитата Qraizer @ 02.11.11, 15:28

Вон, DesweR рассказывает, как неизвестный при компиляции <T> может быть в run-time получен от неизвестного при компиляции объекта, и тем самым запросто заюзан неизвестный при компиляции интерфейс. Что-то не вяжется.

НАсчет неизвестного инетрфейса ничего не знаю. А вот известный интерфейс от неизвестного объекта вполне нормально получить и заюзать как часть функционала своего объекта.

Это-то как раз неудивительно.

template <typename I, typename T>
I& queryInterface(T& src)
{
  return dynamic_cast<I&>(src);
}
 
IA& A = queryInterface<IA>(object);
IB& B = queryInterface<IB>(object);

Ежели так, то и вопросов нет. Но вроде бы у них со scorpion о чём-то магическом разговор шёл. Или я не понял.

Сообщение отредактировано: Qraizer - 02.11.11, 17:43

Цитата Qraizer @ 02.11.11, 15:28

Редко восстребованная фича, когда всё-таки требуется, реализуемая не эдак, лучше, нежели невозможная к реализации без костылей.

При этом в С++ почему-то нет, например, нормального метапрограммирования, поддержки создания DSL, нормальных лямбд, мультиметодов(хотя было неплохое предложение), поддержки аспектно-ориентированного программирования, DbC(тоже было хорошее предложение) и т.д. и т.п. И исправить/добавить это пользователи языка не могут... Есть не очень успешные попытки это делать, как раз на страшных костылях...

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

поддержки аспектно-ориентированного программирования

Эту фичу вообще мало кто "искаропки" поддерживает. Насколько я знаю, в джаве и дотнете библиотеки, реализующие АОП, занимаются или рефлексией, или ещё более мерзопакостной правкой байт-кода. Ну, а из реализаций для плюсов мне приглянулась эта, но я не пробовал.

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

Цитата MyNameIsIgor @ 02.11.11, 18:37

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

поддержки аспектно-ориентированного программирования

Эту фичу вообще мало кто "искаропки" поддерживает.

Я имел не встроенное в язык средство, а, скажем так, возможность реализации пользователями языка.

Цитата Peter Norvig

In Lisp, if you want to do aspect-oriented programming, you just do a bunch of macros and you're there. In Java, you have to get Gregor Kiczales to go out and start a new company, taking months and years and try to get that to work. Lisp still has the advantage there, it's just a question of people wanting that.

D_KEY, никто не будет в один язык запихивать вообще всё, что напридумано в области дискретной математики за 60 лет. В язык вводится то, что восстребовано в достаточной степени. Вот и всё. Множественное наследование реализаций дельфийцами не восстребовано (в немалой степени благодаря пропаганде поставщика средства разработки, впрочем). Нормальное метапрограммирование не восстребовано плюсовиками. Мультиметоды реализуются без костылей, да и необходимость в них не так уж очевидна. Без нормальных лямбд императив обойдётся, вполне достаточно той функциональщины, которая восстребована сейчас. Она 9 лет назад ещё не была восстребована вообще, STL показала вектор, а там как само восстребовалось, так и воплотилось.

Сообщение отредактировано: Qraizer - 02.11.11, 18:51