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

Цитата D_KEY @ 15.03.11, 17:43

korvin, ты можешь сформулировать свою идеи и нормально оформить, желательно с примерами на каком-то языке(реальном или гипотетическом, главное - полный пример синтаксиса с описанием семантики)?

блин, да я ж уже 20 раз приводил пример:

class A {
    public <type> x;
}
 
class B {
    hided A a;
}
 
B b = new B();
b.a.x; // -- работает
b.a;   // -- нет

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

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

Добавлено 15.03.11, 17:57

Цитата D_KEY @ 15.03.11, 17:46

Ничем. Только это не класс. Это структура. Интерфейсом, фактически, тут являются сами данные.

а если я добавлю ключевое слово Class? =) или сделаю поля приватными, а наружу выставлю метод, который возвращает список = [x, y, z]? так устроит? =)

Добавлено 15.03.11, 17:59

Цитата D_KEY @ 15.03.11, 17:46

Потому, что это нарушает такое простое понятие, как инкапсуляция. Но тебе никто не мешает(если это действительно необходимо) сделать методы get и set, работающие именно с объектами данных классов. Ты же хочешь чего-то среднего...

какие еще get и set? теперь я тебя не пойму

Добавлено 15.03.11, 18:00

Цитата D_KEY @ 15.03.11, 17:54

Ты мне скажи, как клиент узнает интерфейс того поля, к которому будет обращаться, если не будет знать его класса?

это особая, уличная магия спецификатора hided

Цитата korvin @ 15.03.11, 17:54

я не знаю, что тут может быть непонятного.

Как клиент узнает об интерфейсе x, если ты говоришь, что он не будет знать о классе A.

Цитата

Цитата D_KEY @ 15.03.11, 17:46

Ничем. Только это не класс. Это структура. Интерфейсом, фактически, тут являются сами данные.

а если я добавлю ключевое слово Class? =) или сделаю поля приватными, а наружу выставлю метод, который возвращает список = [x, y, z]? так устроит? =)

Неа

Цитата

Цитата D_KEY @ 15.03.11, 17:54

Ты мне скажи, как клиент узнает интерфейс того поля, к которому будет обращаться, если не будет знать его класса?

это особая, уличная магия спецификатора hided

Так клиент все-таки будет знать о классе A или ему hiden ему расскажет об интерфейсе класса A путем телепатического сеанса связи?

Цитата D_KEY @ 15.03.11, 18:06

Неа

why?

Цитата D_KEY @ 15.03.11, 18:06

Так клиент все-таки будет знать о классе A или ему hiden ему расскажет об интерфейсе класса A путем телепатического сеанса связи?

почему телепатического? нормального, вербального =)

Цитата D_KEY @ 15.03.11, 17:09

IL_Agent, кульно. А вот касательно

не понял. Таки AS работает? Хто обманывает? Или чего я не учёл?

Работает. А кто-то говорит, что не работает ?
Но я бы такой, имхо более жизненный пример вызова привёл:

  void Main()
      {
        A obj = new A();
        CallA(obj);
        CallB(obj);    
      }
      
      void CallA(IA a)
      {
        a.f();//IA.f
      }
      
      void CallB(IB b)
      {
        b.f();//IB.f
      }

Цитата Qraizer @ 15.03.11, 17:08

Аргументируй, плз. Я к примеру не вижу логики в том, чтобы использовать именно агрегацию. Этот компонент будет реализовывать оба эти интерфейса, а не использовать их. Агрегации тут ИМХО не место.

Извени, но это бред, ты вообще разделяешь прикладные и системные задачи? Реализация класса TCP как раз относится к системному уровню и в дальнейшем служит для решения прикладной задачи - реализации класса History (или что там было) и это для конечного пользователя твоего компонента куда важнее, нежеле сама внутренняя кухня, к тому же такое разделение по уровням делает классы (а конкретно TCP) более независимыми и пригодными к повторному использованию (ICQ, почтовый клиент и т.д и т.п.).

Цитата Qraizer @ 15.03.11, 17:08

Не забыл. Знаю, есть. Только та фраза относилась не к моему вопросу о разрешении коллизий, а твоему (точнее korvin-а) примеру о невозможности вызова A.f, если есть IB.f, причём никакой AS тут не поможет. Как обычно ты попробовал что-то сказать лишь бы что-то сказать.

О какой "невозможности" ты тогда говоришь?
И да, я как обыно вызываю у тебя батхерт.

Цитата Qraizer @ 15.03.11, 17:08

И? Ты сказал то же, что и я. Почему, если А реализует и parent в частности, то его нельзя передать в функцию, принимающую интерфейс parent? Или Shaggy что-то путает?

Чего? Я вообще ничего похожего на твои слова не говорил Либо ещё раз внимательно перечитай, либо обращайся к "первоисточнику" - Сущность технологии СОМ.
Shaggy ничего не путает.

Цитата Qraizer @ 15.03.11, 17:08

Ты действительно этого хочешь? Пошагово?

Гммм... ну и где ты fail нашёл?

type
  ISome1 = interface
    procedure Method1;
  end;
 
  ISome2 = interface
    procedure Method2;
  end;
 
//Можешь даже дать одинаковые имена методам Method1 и Method2 - всё равно будет работать
 
  TSome1 = class(TInterfacedObject, ISome1)
    procedure Method1;
  end;
 
  TSome2 = class(TInterfacedObject, ISome2)
    procedure Method2;
  end;
 
 
  TSuperSome = class(TInterfacedObject, ISome1, ISome2)
  strict private
    FSome1: ISome1;
    FSome2: ISome2;
  public
    constructor Create;
    property Some1: ISome1 read FSome1 implements ISome1;
    property Some2: ISome2 read FSome2 implements ISome2;
  end;
 
 
procedure TSome1.Method1;
begin
  Writeln('TSome1.Method1');
end;
 
procedure TSome2.Method2;
begin
  Writeln('TSome2.Method2');
end;
 
 
constructor TSuperSome.Create;
begin
  FSome1 := TSome1.Create;
  FSome2 := TSome2.Create;
end;
 
 
procedure SomeProc1(Some: ISome1);
begin
  Some.Method1;
end;
 
procedure SomeProc2(Some: ISome2);
begin
  Some.Method2;
end;
 
...
 
var
  SuperSome: TSuperSome;
begin
  SuperSome := TSuperSome.Create;
 
  SomeProc1(SuperSome);
  SomeProc2(SuperSome);
 
  SuperSome.Free;
end;

TSome1.Method1
TSome2.Method2

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

Добавлено 15.03.11, 19:31
Qraizer
Если ты, говоря о "невозможности вызова", имел ввиду это:

Цитата IL_Agent @ 15.03.11, 18:33

Цитата D_KEY @ 15.03.11, 17:09

IL_Agent, кульно. А вот касательно

не понял. Таки AS работает? Хто обманывает? Или чего я не учёл?

Работает. А кто-то говорит, что не работает ?
Но я бы такой, имхо более жизненный пример вызова привёл:

  void Main()
      {
        A obj = new A();
        CallA(obj);
        CallB(obj);    
      }
      
      void CallA(IA a)
      {
        a.f();//IA.f
      }
      
      void CallB(IB b)
      {
        b.f();//IB.f
      }

То в Delphi такое работает (см. внимательнее мой пример).

Сообщение отредактировано: DesweR - 15.03.11, 19:31

korvin, если я правильно тебя понял, тебе понадобился кортеж. Вполне понятная и распространённая штука. У нас есть в boost-е, в новой редакции Стандарта будет в стандартной библиотеке. Если есть желание посмотреть поближе, то могу на коленке написать несколько ущербную, по более понятную, чем общий случай, реализацию. Только сразу предупреждаю, там будет множественное наследование реализаций. Ужас, да. А, и ещё для простоты обращение к элементам будет всё-таки по индексам. Не сахаром единым, всё-таки. Только ближе к выходным. Мне тут коммандировка в Питер светить начала, надо успеть подготовиться на всякий случай. Не уверен, что среди недели найду времени накодить что-то неабстрактное.
Э-э-э... IL_Agent, смотри чуть ниже. То, что AS в Дельфи есть и как-то работает, я и не сомневался. Только вот теперь подозреваю, что не вполне понимаю, что он на самом деле делает.

Цитата DesweR @ 15.03.11, 19:14

Извени, но это бред, ...

Та пожалуйста. Ты тоже прости KILLER-а, что его в теме счас нет, нето он уже получил бы банку, чем несказанно тебя б порадовал. Я не он, из себя выходить не буду. Ты б перестал темы подменять. Не верю, что до тебя так и не дошло, о чём речь.

Цитата DesweR @ 15.03.11, 19:14

Гммм... ну и где ты fail нашёл?

Гы. Это решение у меня идёт самым первым из трёх. Примечания читал? Ау, KILLER! Никто KILLER-а не видел? Так занятно было читать дцать страниц воды и завидовать его волевым усилиям попасть не более чем на устное...

Цитата DesweR @ 15.03.11, 19:14

О какой "невозможности" ты тогда говоришь?

Вот предложенный korvin-ом код. Вот им ожидаемое (по-моему там один B.f лишний, но тогда не посчитал обращать на это внимания). А вот тут твой ему облом. Тот факт, что B слопал две реализации интерфейса IA и молча слил их в одну, оказался Дельфи не по зубам. А korvin, небось, обидился. Ему, вишь вон, как раз много A понадобилось внутри одного B. Вот и агрегируйся ему на здоровье. Потом можно будет сравнить скорострельность динамического полиморфизма List<> и дженериков в частности в run-time и статического полиморфизма шаблонов в compile-time.

Сообщение отредактировано: Qraizer - 15.03.11, 23:20

Цитата Qraizer @ 15.03.11, 23:09

Ты б перестал темы подменять. Не верю, что до тебя так и не дошло, о чём речь.

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

Цитата Qraizer @ 15.03.11, 23:09

Никто KILLER-а не видел? Так занятно было читать дцать страниц воды и завидовать его волевым усилиям попасть не более чем на устное...

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

Цитата Qraizer @ 15.03.11, 23:09

А вот тут твой ему облом. Тот факт, что B слопал две реализации интерфейса IA и молча слил их в одну, оказался Дельфи не по зубам.

Qraizer, а ты не обратил внимание на тот факт, что метод f у меня виртуальный?

  A = class(TInterfacedObject, IA)
    procedure f; virtual;
  end;
 
  B = class (A, IB)
    procedure f; override;
    procedure g;
  end;

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

type
  IA = interface
    procedure f;
  end;
 
  IB = interface (IA)
    procedure g;
  end;
 
  A = class(TInterfacedObject, IA)
    procedure f; //virtual;
  end;
 
  B = class (A, IB)
    procedure f; //override;
    procedure g;
  end;
 
 
procedure A.f;
begin
  Writeln( 'A.f' );
end;
 
procedure B.f;
begin
  Writeln( 'B.f' );
end;
 
procedure B.g;
begin
  Writeln( 'B.g' );
end;
 
 
procedure f1 (const x : IA);
begin
  x.f;
end;
 
procedure f2 (const x : IB);
begin
  x.f;
end;
 
...
 
var
  x : B;
begin
  x := B.Create;
  f1( x );
  f2( x );
end;

A.f
B.f

Ещё примеры:

  A = class(TInterfacedObject, IA)
    procedure f; //virtual;
  end;
 
  B = class (A, IB)
    procedure f; //override;
    procedure IB_f;
    procedure IB.f = IB_f;
    procedure g;
  end;

A.f
B.IB_f

с виртуальными методами:

  A = class(TInterfacedObject, IA)
    procedure f; virtual;
  end;
 
  B = class (A, IB)
    procedure f; override;
    procedure IB_f;
    procedure IB.f = IB_f;
    procedure g;
  end;

B.f
B.IB_f

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

Добавлено 16.03.11, 03:32

Цитата Qraizer @ 15.03.11, 23:09

Потом можно будет сравнить скорострельность динамического полиморфизма List<> и дженериков в частности в run-time и статического полиморфизма шаблонов в compile-time.

Но это только в условиях, когда на этапе компиляции всё предопределено

Сообщение отредактировано: DesweR - 16.03.11, 03:46

Цитата Qraizer @ 15.03.11, 23:09

korvin, если я правильно тебя понял, тебе понадобился кортеж. Вполне понятная и распространённая штука. У нас есть в boost-е, в новой редакции Стандарта будет в стандартной библиотеке. Если есть желание посмотреть поближе, то могу на коленке написать несколько ущербную, по более понятную, чем общий случай, реализацию. Только сразу предупреждаю, там будет множественное наследование реализаций. Ужас, да. А, и ещё для простоты обращение к элементам будет всё-таки по индексам. Не сахаром единым, всё-таки. Только ближе к выходным. Мне тут коммандировка в Питер светить начала, надо успеть подготовиться на всякий случай. Не уверен, что среди недели найду времени накодить что-то неабстрактное.

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

Цитата Qraizer @ 15.03.11, 23:09

А korvin, небось, обидился. Ему, вишь вон, как раз много A понадобилось внутри одного B.

вовсе нет, я уже приводил цитату А.Кея(не путать с D_KEY), где было и про время связывания в ООП. а то, что мне сейчас нужно отношения к этому не имеет. или ты покажешь множественное наследование от одного и того же класса несколько раз с возможностью доступа к этим объектам?

Добавлено 16.03.11, 04:15
во, пришла на ум аналогия из мира Unix:
C -- каталог с режимом доступа 711 (или 771)
C/a -- каталог со стандартным режимом доступа 755
т.е. просмотреть список файлов и каталогов C (и соответственно обратиться к ним по имени) -- C/a нельзя, но выполнить скрипт из C/a/foo.sh -- можно

единственно, что в классе C можно определять к каким частям какой доступ, т.е.
C/private -- 700
C/protected -- 770
C/public -- 777

C/hiden -- 711

Сообщение отредактировано: korvin - 16.03.11, 04:15

Цитата korvin @ 16.03.11, 03:57

т.е. просмотреть список файлов и каталогов C (и соответственно обратиться к ним по имени) -- C/a нельзя, но выполнить скрипт из C/a/foo.sh -- можно

И когда в последний раз ты это видел?

Цитата Мяут-Настоящий @ 16.03.11, 04:44

И когда в последний раз ты это видел?

никогда =) но ты обещал более практичные языковые концепции, где они? =)

Цитата DesweR @ 16.03.11, 03:31

Да я и не собирался ничего подменять, ...

Ага, конечно. Твои рассуждения про системный и прикладной уровни ПО мне померещились. Хорошо, раз ты против, соглашусь, что суть проблемы с коллизиями имён до тебя так и не дошла.

Цитата DesweR @ 16.03.11, 03:31

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

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

Цитата DesweR @ 16.03.11, 03:31

Qraizer, а ты не обратил внимание на тот факт, что метод f у меня виртуальный? ... И никто ничего не сливал, это всего навсего полиморфизм,...

За кого ты меня держишь? Это уже граничит с оскорблением. Какой же я терпеливый сегодня. Последний раз объясняю. Метод IA.f реализован в B дважды. Дваж-ды. От разных интерфейсов. Первый, от A, второй от IB. Какое право хвалёная объектная модель молча слила их в один? Меня всегда учили, что это неоднозначность, о которой компилятор должен орать во всё горло. У нас они сольются только при виртуальном наследовании. Потому что только в этом случае это действительно будет один и тот же метод. Иначе я должен либо явно указывать, какой метод из двух дёргаю, что и делается кастом, либо устранить коллизию, что и сделал Повстанець 10 страниц назад, причём сразу после вопроса. А раз так, то

Цитата DesweR @ 16.03.11, 03:31

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

нарушением инкапсуляции является как раз то, что делает в таком случае Дельфи. Ему скASали "смотри в A", он ответил "угу" и вызвал из B, идиот. У нас всё в порядке, сказал, что хочу вызвать метод от первого IA, его перекрытый и вызовется, т.е A::f(), не сказал - вызовется от второго, т.е. B::f(). Забирайте вашу монолитность объектов.

Цитата DesweR @ 16.03.11, 03:31

Но это только в условиях, когда на этапе компиляции всё предопределено

У korvin-а тоже на этапе компиляции определено. Или ты видел у него требование подменять имена x, y, z прям в run-time?

Слушай, давай ты всё-таки не будешь читать по диагонали, а? Четвёртый пост воду лью в тему.

Цитата korvin @ 16.03.11, 03:57

нет, кортеж тут не при чем

Ну, да, не совсем. Немного более строг в одном и попроще в другом. Но очень похож.

Цитата korvin @ 16.03.11, 03:57

или ты покажешь множественное наследование от одного и того же класса несколько раз с возможностью доступа к этим объектам?

Ну в общем да. Не явно, конечно, но эффект именно таков. Собственно, 10 страниц назад ты это уже видел. Только то был кривой дизайн, а тут это будет работать на благо. Никто ж не заставляет использовать всегда виртуальное наследование. Там будет только проблема с диспетчеризацией. Но проиндексировать в compile-time несложно, а кастами выбрать нужный и подавно. Никакого полиморфизма в run-time, будет словно оно всё плоское.
Единственное что, боюсь, не получится, это попроще скрыть от неподобающего юзания составные элементы. Но ты как бы был согласен, что в случае наследования это уже не так принципиально, как в случае агрегации.

Добавлено 16.03.11, 05:15
Ах да, DesweR, ещё об этом забыл:

Цитата DesweR @ 15.03.11, 19:14

Я вообще ничего похожего на твои слова не говорил

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

Сообщение отредактировано: Qraizer - 16.03.11, 05:20

Цитата Qraizer @ 16.03.11, 05:09

Ага, конечно. Твои рассуждения про системный и прикладной уровни ПО мне померещились.

Ещё раз повторяю, это было небольшое ответвление касательно конкретно твоей абстрактной задачи.

Цитата Qraizer @ 16.03.11, 05:09

Хорошо, раз ты против, соглашусь, что суть проблемы с коллизиями имён до тебя так и не дошла.

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

Цитата Qraizer @ 16.03.11, 05:09

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

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

Цитата Qraizer @ 16.03.11, 05:09

За кого ты меня держишь? Это уже граничит с оскорблением. Какой же я терпеливый сегодня. Последний раз объясняю. Метод IA.f реализован в B дважды. Дваж-ды. От разных интерфейсов. Первый, от A, второй от IB ...

Давай ещё раз, и кто тут ещё воду льёт, метод IA.f не реализован в B, он реализован в классе А, который в свою очередь наследует класс B, в самом же В реализован IВ.f, это явно видно в объявлении класса:

type
  IA = interface
    procedure f;
  end;
 
  IB = interface(IA)
    procedure f;
  end;
 
  A = class(TInterfacedObject, IA)//<- написано, что класс А реализует интерфейс IA
    procedure f;//реализация метода IA.f
  end;
 
  B = class(A, IB)//<- написано, что класс В реализует интерфейс IВ и ничего другого, точка
    procedure f;//реализация метода IB.f
  end;
 
 
procedure A.f;
begin
  ShowMessage( 'A.f' );
end;
 
procedure B.f;
begin
  ShowMessage( 'B.f' );
end;
 
 
procedure f1 (const x : IA);
begin
  x.f;
end;
 
procedure f2 (const x : IB);
begin
  x.f;
end;
 
...
 
var
  x : B;
begin
  x := B.Create;
  f1( x );
  f2( x );
end;

A.f
В.f

Почему так? Если не читать по диагонали, я уже объяснял в своём прошлом посте "идеология COM".
Чтобы сократить нашу переписку, заранее рассмотрим ещё парочку вариаций:
1. Каждый интерфейс IA и IB реализовывают отдельные классы A и B соответственно.

type
  IA = interface
    procedure f;
  end;
 
  IB = interface
    procedure f;
  end;
 
  A = class(TInterfacedObject, IA)
    procedure f;
  end;
 
  B = class(TInterfacedObject, IB)
    procedure f;
  end;

Есть SuperClass, который объединяет эти реализации путём делигации (собственно уже приводил такой пример):

type
  IA = interface
    procedure f;
  end;
 
  IB = interface
    procedure f;
  end;
 
  A = class(TInterfacedObject, IA)
    procedure f;
  end;
 
  B = class(TInterfacedObject, IB)
    procedure f;
  end;
 
  SuperClass = class(TInterfacedObject, IA, IB)//в SuperClass мы не пишем, а делегируем реализации интерфейсов IA и IB
  strict private
    FA: IA;
    FB: IB;
  public
    constructor Create;
    property RA: IA read FA implements IA;
    property RB: IB read FB implements IB;
  end;
 
 
procedure A.f;
begin
  ShowMessage( 'A.f' );
end;
 
procedure B.f;
begin
  ShowMessage( 'B.f' );
end;
 
constructor SuperClass.Create;
begin
  FA := A.Create;
  FB := B.Create;
end;
 
 
procedure f1 (const x : IA);
begin
  x.f;
end;
 
procedure f2 (const x : IB);
begin
  x.f;
end;
 
...
 
var
  x : SuperClass;
begin
  x := SuperClass.Create;
  f1( x );
  f2( x );
end;

A.f
В.f

Всё работает и ожидалось.

2. Класс SuperClass сам реализовывает интерфейсы IA и IB, в этом случае мы разруливаем коллизию с наименованием методов.

type
  IA = interface
    procedure f;
  end;
 
  IB = interface
    procedure f;
  end;
 
 
  SuperClass = class(TInterfacedObject, IA, IB)
    procedure Af;
    procedure IA.f = Af;
    procedure Bf;
    procedure IB.f = Bf;
  end;
 
 
procedure SuperClass.Af;
begin
  ShowMessage( 'A.f' );
end;
 
procedure SuperClass.Bf;
begin
  ShowMessage( 'B.f' );
end;
 
 
procedure f1 (const x : IA);
begin
  x.f;
end;
 
procedure f2 (const x : IB);
begin
  x.f;
end;
 
...
 
var
  x : SuperClass;
begin
  x := SuperClass.Create;
  f1( x );
  f2( x );
end;

И снова:

A.f
В.f

Ну и путь будет третий вариант:

type
  IA = interface
    procedure f;
  end;
 
  IB = interface
    procedure f;
  end;
 
 
  SuperClass = class(TInterfacedObject, IA, IB)//Да! реализовываем оба интерфеса и сливаем всё в один метод
    procedure f;
  end;
 
 
procedure SuperClass.f;
begin
  ShowMessage( 'SuperClass.f' );
end;
 
 
procedure f1 (const x : IA);
begin
  x.f;
end;
 
procedure f2 (const x : IB);
begin
  x.f;
end;
 
...
 
var
  x : SuperClass;
begin
  x := SuperClass.Create;
  f1( x );
  f2( x );
end;

SuperClass.f
SuperClass.f

Qraizer, может быть ты этого варианта ожидал? Тогда я в недоумении, это полностью законная конструкция и компилятор тут не дурак - мы сами этого захотели.

Цитата Qraizer @ 16.03.11, 05:09

У korvin-а тоже на этапе компиляции определено. Или ты видел у него требование подменять имена x, y, z прям в run-time?

Не цепляйся, это пока мысли в слух.

Цитата Qraizer @ 16.03.11, 05:09

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

Внезапно! Я пришёл к выводу, что выполнятся должен не только сигнатурный контракт класса и интерфейса, но и семантический (лукавлю конечно, этот вывод выводится в книге "Сущность технологии COM"). Не знаю кто там с пеной у рта, только вот не надо за меня решать, как я думал и думаю.

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

Цитата Qraizer @ 15.03.11, 23:09

Э-э-э... IL_Agent, смотри чуть ниже. То, что AS в Дельфи есть и как-то работает, я и не сомневался. Только вот теперь подозреваю, что не вполне понимаю, что он на самом деле делает.

Ну я-то про C# рассказывал. Что делает ? Приводит тип к требуемому (К.О. ).Пруф.
В приведённом примере используется т.н. Explicit Interface Implementation. Т.е. метод можно вызвать, только имея ссылку на интерфейс. При этом вызывается метод именно этого интерфейса. По ссылке на сам объект метод не доступен.

Добавлено 16.03.11, 07:38
Как в делфи - не знаю. Также, наверное ?

Сообщение отредактировано: IL_Agent - 16.03.11, 07:38

Цитата IL_Agent @ 16.03.11, 07:34

Как в делфи - не знаю. Также, наверное ?

Да также, всё это внутренняя кухня с VMT.

в делфи as служит для приведения интерфейса класса к интерфейсу субкласса, точнее для возврата утерянной информации о классе, когда мы TSome передаем в подпрограмму или контейнер, ожидающий TObject например

Моя ошибка -- забыл, что он для такого приведения нужен, а не обратного, как в примере у Игоря

Если непонятно объяснил, позже покажу кодом

Добавлено 16.03.11, 08:01

Цитата DesweR @ 16.03.11, 07:52

Да также, всё это внутренняя кухня с VMT.

не совсем. Как я понял

C#: TSome as TObject
Delphi: TObject as TSome