Ответ на »сообщение 1670« (Сергей Губанов)
___________________________
P. S.
Вот, нашел оригинал:

№ 1522  27-07-2004 17:24
Любой полиморфный тип имеющий в своем интерфейсе N - операций, автоматически включает в себя все
g_N = N + N*(N-1)/2! + N*(N-1)*(N-2)/3! + ... = 2^N - 2
штук более мелких полиморфных типов.

http://www.delphikingdom.com/asp/talktopic.asp?ID=285&Order=0&Count=10&pNo=15

Ответ на »сообщение 1668« (Владимир)
Далее. Для меня (это только мое личное мнение!) само по себе понятие "интерфейс" особо-то и не нужно выражать в виде программной сущности, "объекта программы". Это - скорее "организационная единица объединения совокупности" функций.
Помниться, я о чем-то подобном тут писал пару месяцев назад. Об автоматическом включении одного интерфейса в другой. То есть если есть интерфейсы I1 и I2:

I1 = INTERFACE
  PROCEDURE f();
  PROCEDURE g();
END;

I2 = INTERFACE
  PROCEDURE f();
  PROCEDURE g();
  PROCEDURE h();
  PROCEDURE k();
END;

не связанные друг с другом "наследованием", то все-равно интерфейс I2 включает в себя интерфейс I1. (I1 входит в I2, т.к. в I2 есть все процедуры I1). Это отдаленно напоминает включение типов (type inclusion) REAL >= SHORTREAL >= LONGINT >= INTEGER >= SHORTINT >= BYTE. Другими словами - японским калькулятором тоже можно гвозди забивать. Аргументировал я это тем, что количество таких "под-интерфейсов" у интерфейса состоящего из N методов растет экспоненциально (2^N), а значит разработчику интерфейса очень сложно (физически невозможно) расписать заранее (на момент написания компонента) все возможные способы его использования (то есть написать, что компонент поддерживает и такой интерфейс и сякой и эдакий - слишком много их ~ 2^N).

Ответ на »сообщение 1667« (Ivan)
___________________________
Если честно - просто пока этим не занимался...
Кстати, раз уж пошли такие вопросы, есть мысль! Сейчас убегаю на оекции, вернусь - оформлю и озвучу... :о)

Ответ на »сообщение 1664« (Сергей Губанов)
___________________________
QUERY
По прошествии нескольких часов подумалось, что это вы из COM QueryMultipleInterfaces (насколько помнится, после многолетней неработы с мс-компонентной моделью)?
Опять же, насколько я помню эта функция была введена как раз для получения максимальной производительности при маршалинге с удалёнными объектами... Она избыточна в плане просто узнавания и затребования конкретного интерфейса... Я думаю можно пока более простыми путями идти (с полкчением доступа к одному конкретному интерфейсу).

Далее. Для меня (это только мое личное мнение!) само по себе понятие "интерфейс" особо-то и не нужно выражать в виде программной сущности, "объекта программы". Это - скорее "организационная единица объединения совокупности" функций.
Пример из жизни: один мой одноклассник, осерчав на гвоздь, вылезший из парты в кабинете физики и порвавший рукав его вязанного свитера, "вернул его на место", несколько раз ударив по шляпке япноским импортным тестером... Это в советское время! :о) То есть, хоть тестер на молоток и не был похож (чистое представление интерфейса "молоток"), но функцию "ударить по чему-нибудь" мы от него смогли получить... :о) Кстати, с нужным результатом... Хотя и с "побочными эффектами" в виде выброшенного учителем "исключения" "...завтра с отцом в школу!..." :о)))

С уважением

В контрибуциях к Бутылке есть модули Data, DataIO. Я так понял, они не поддерживают сохранения перекрёстных ссылок (как Stores в ЧЯ). Может я чего проглядел? Есть ли в Бутылке модули с соответствующей функциональностью?

Ответ на »сообщение 1664« (Сергей Губанов)
___________________________
Мысль на счет динамического приведения типов....
Мне нравится. Причём, тут "автоматом" и вопрос о наследовании "по интерфейсной линии" решается!
Исходники компилятора с системой идут - дерзайте! Руководства и статьи об OPC - поищите на цюрихском сайте. Удачи!

С уважением

Ответ на »сообщение 1660« (Ivan)
___________________________
разработчикам весьма нехватает в языке трёх вещей:
1. Абстрактных методов. В базовых классах куча комментариев (* abstract *) и халтов.
2. Protected-секций в объектах. В некоторых базовых классах стоят комментарии типа "использовать только в наследниках" у полностью открытых переменных
Всё “на подходе”... :о)
Я так понимаю, что они очередной “заплыв” на языковые средства этой осенью начнут...

Я бы ещё добавил, что не хватает, всё-таки битовых операций (но! без привязки, например сдвигов к знаковости аргумента) – с множествами подчас ОЧЕНЬ неочевидно и громоздко, когда на низком уровне работаешь...
Ну и, конечно обязательно нужно ввести инициализацию структур и массивов начальными значениями. Пусть даже не при объявлении, а конструктами, как в Аде в самом коде. Способ из Турбо-версий, по-моему, подходит, по удобству.

Сам главный программер у них – БОЛЬШОЙ поклонник Дельфи и склоняется к ивведению в язык отработанных и доказавших свою полезность дельфийских фич в язык...

3. (неочевидно) Некоторого механизма запрета многопоточного использования объектов.
Очень неочевидно. Пока мне видится только “организационный момент”...
Желание ввести такие ограничения не понятны. Тут скорее на уровне организации взаимодействия между объектами в коде...

Были ли идеи расширить язык в этом направлении? И если были, то почему тх отвергли?
Ничего не отвергается. Всё “перетирается”... :о) Люди и деньги... :о) :о(

С уважением

Мысль на счет динамического приведения типов. Если
p: OBJECT - некий объект, и
a: ModuleA.DefinitionA; - некий интерфейс, то для "вытаскивания интерфейса из объекта" в языках программирования обычно используют конструкции следующего вида:

1) a := ModuleA.DefinitionA(p);
2) a := p as ModuleA.DefinitionA;
3) a = dynamic_cast<ModuleA.DefinitionA>(p);
4) p.QueryInterface(ModuleA.DefinitionA, a)

Все эти конструкции объединяет то, что в них явно прописывается имя ModuleA.DefinitionA запрашиваемого интерфейса. Но зачем? Ведь компилятору и так известен тип переменной

VAR a: ModuleA.DefinitionA;

Зачем по сто раз писать одно и тоже?

Что если ввести такую специальную (псевдо)процедуру

PROCEDURE QUERY(p: OBJECT; OUT ....): BOOLEAN;

которая будет выполнять динамическое приведение типов:

PROCEDURE Proc(p: OBJECT);
VAR pa: ModuleA.DefinitionA;
    pb: ModuleB.DefinitionB;
    pc: ModuleC.DefinitionC;
BEGIN
  IF QUERY(p, pa, pb, pc) THEN
    pa.f();
    pb.g();
    pc.h();
  END
END Proc;

Первым аргументом у процедуры QUERY является объект-имплементатор интерфейсов, остальные параметры - есть OUT параметры соответствующие интерфейсным переменным. Если объект реализует запрашиваемые интерфейсы, то в этих выходных параметрах прописываются # NIL значения, а процедура возвращает TRUE. В противном случае, процедура возвращает FALSE, а все OUT параметры устанавливаются в NIL. Почему это псевдо процедура - да потому что ее должен генерировать сам компилятор. То есть для вышеприведенного примера, компилятор автоматически должен сгенерировать такую процедуру:

PROCEDURE QUERY(p: OBJECT; OUT a: ModuleA.DefinitionA; OUT b: ModuleB.DefinitionB; OUT c: ModuleC.DefinitionC): BOOLEAN;

С уважением,
Сергей Губанов

Ответ на »сообщение 1662« (info21)
Будьте добры еще раз ссылку дать на сей диссер, а табличку привести прямо здесь (и др. самые интересные таблички).

Начало отсюда http://www.cs.inf.ethz.ch/~muller/ далее по ссылке Publications идем в пункт
P.J. Muller, The Active Object System -- Design and Multiprocessor Implementation, PhD Thesis, ETH Zьrich, Switzerland, 2002.
Откуда попадаем на страницу скачивания диссера
http://e-collection.ethbib.ethz.ch/cgi-bin/show.pl?type=diss&nr=14755

Точный адрес самого диссера:
http://e-collection.ethbib.ethz.ch/ecol-pool/diss/fulltext/eth14755.pdf

На счет таблички.
Про скорость там в основном приведены графики, так что их здесь не покажешь. Цифры такие:

Minimal system call

Aos  0.014 микро секунд
Linux 0.433 микро секунд

т.е. разница ~ 30 раз.

Время создания процесса:

Aos  20 микро секунд
Linux от ~105 - до 120 микро секунд

в зависимости от количества уже существующих (приведен рисунок для N = 10, 100, 1000, 10000)

В остальных табличках разница между Aos и Linux составляет проценты, а не разы.

Ответ на »сообщение 1653« (Владимир)
___________________________

Ответ на »сообщение 1648« (Сергей Крысов)
___________________________
.. диссер по АОС дочитал, круто ...
Как Вам понравилась табличка со сравнением времён перекличений контекстов? :о)

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

Заранее спасибо.