Ответ на »сообщение 1649« (avk02)
___________________________
Так там ещё пароль и логин нужны... :(
Не знаю, в мозилле захожу, как "к себе до дому"... :о) анонимно, без военщины...

Прошу прощения.
Фразу
А что, обязательно должно индексироваться?
читать как цитату:
А что, обязательно должно индексироваться?

Ответ на »сообщение 1639« (Ivan)
___________________________

Качать надо отсюда: ftp://bluebottle.ethz.ch/
Там каталоги для разных веток. Докачка есть.

Так там ещё пароль и логин нужны... :(


А вот ещё - в поисковиках на фразу AosCD.zip ничего нет - [bluebottle.]ethz.ch не индексируется?

А что, обязательно должно индексироваться?

Я так понимаю, страницы на сайте статичные, так что не должны быть проигнорированы - разве что это сайт настроен так...

Уфф, наконец-то диссер по АОС дочитал, круто ...

Ответ на »сообщение 1643« (Владимир)
___________________________
>>>В том мире программирования, куда я стопы свои направил...

Владимир, и как этот мир называется, в котором нет наследования "как класса"?!

Ответ на »сообщение 1645« (Владимир) Уточнение
___________________________
А организация инфраструктуры её обеспечения - не дело компонента.
Имеется в виду, конечно, - не дело клиента.

Ответ на »сообщение 1644« (Сергей Губанов)
___________________________
А какая разница?
По сути своей Вам ведь не столько носитель функциональности интересен, сколько его возможность предоставлять оную функциональность.
Как и в жизни, Вы не конкретно менеджерв строительной организации просите крышу перекрыть... То есть договор-то Вы с ним заключаете (через него с фирмой), но кто конкретно будет на коньке висеть - Вас не интересует. Менеджер просто говорит, что эту работу они могут выполнить. Даже если и не могут, то они переадресуют её нанимаемой иретьей фирме. Но Вас это - не волнует, Вам нужно, что бы был выполнен весь комплекс работ, связанных с крышей... :о)
По сути дела, гнобная МС, таки ввела очень ценный приём работы - не указатели на объекты, а именно на интерфейсы - описания гарантированной функциональности. Это уже дело конкретной архитектуры, как там будут агрегатные отношения "разгребаться". Клиенту интерфейсов это не должно быть известно, кто предоставил интерфейс. Была затребована функциональность, и был получен ответ "есть" или "нет". А организация инфраструктуры её обеспечения - не дело компонента. Даже намёка как это реализовано.

С уважением

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

В том мире программирования, куда я стопы свои направил, хватает и просто проверки наличия реализации запрашиваемого интерфейса. Просто по причине отсутствия в оном мире наследования
В тех примерах наследования нет (реализация интерфейса - это же не наследование). А теперь вопрос: У кого Вы проверяете наличие реализации запрашиваемого интерфейса? У одного объекта? А что если тот объект является агрегатом других объектов. Когда Вы запрашиваете услугу по интерфейсу, то не все ли Вам равно кто будет оказывать эту услугу - сам объект-агрегат или же какой-то из (инкапсулированных) компонентов этого агрегата (Вы то эти два случая различить друг от друга не сможете). Или, быть может, какой-то из компонентов-компонентов находящихся еще глубже по уровням агрегации? Чтобы было все симметрично, то этот механизм должен работать и в обратную сторону. То есть когда компонент запрашивает услугу по какому-то интерфейсу у своего агрегата, то не все ли ему равно кто именно окажет эту услугу - его непосредственный агрегат или, быть может, еще более крупный агрегат внутри которого встроен первый агрегат или, теоретически, еще-перееще более крупный агрегат? Компонент эти случаи тоже друг от друга отличить не сможет. В том форуме, на который была направлена ссылка, обсуждаеются вопросы связанные с тем что будет после современного ООП. Уважаемый ASU предложил, что это будет Парадигма агрегирования. То есть если в рамках ООП все есть объект, то в рамках этой парадигмы все есть агрегат. Если рассуждать логически, то в рамках этой парадигмы, должно быть три способа запрашивать у агрегата реализацию интерфейса:
1) Обычный запрос непосредственной реализации самим агрегатом - GetDirectInterface
2) Запрос реализации интерфейса либо лично агрегатом, либо кем-то из его компонентов - GetDescendInterface.
3) Запрос реализации интерфейса либо лично агрегатом, либо кем-то из его вышестоящих агрегатов - GetAscentInterface.

Самый крупный агрегат - среда исполнения (агрегирует всех).
Самый мелкий агрегат - тот который уже ни кого не агрегирует (это обычный ООП объект).

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

Ответ на »сообщение 1642« (Сергей Губанов)
___________________________
Хотелось бы узнать мнение "магов вне категорий"Да лпдно Вам! Это я после того, как Лукьяненко обчитался... :о))) по поводу следующих синтаксических конструкций
ASCENT A: ISomeInterface DO A.DoSmth(); END;
DESCEND P: IPoint DO P.SetPosition(x, y); END;
смысл которых изложен там:
http://progz.ru/forum/viewtopic.php?p=38522#38522

В том мире программирования, куда я стопы свои направил, хватает и просто проверки наличия реализации запрашиваемого интерфейса. Просто по причине отсутствия в оном мире наследования "как класса". :о)

С уважением

Хотелось бы узнать мнение "магов вне категорий" по поводу следующих синтаксических конструкций

ASCENT A: ISomeInterface DO A.DoSmth(); END;

DESCEND P: IPoint DO P.SetPosition(x, y); END;

смысл которых изложен там:
http://progz.ru/forum/viewtopic.php?p=38522#38522

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