OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 24 Май, 2018 01:34

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 54 ]  На страницу Пред.  1, 2, 3
Автор Сообщение
 Заголовок сообщения: Re: Активные структуры данных
СообщениеДобавлено: Вторник, 13 Май, 2008 01:12 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Илья Ермаков писал(а):
И более статичный... Ибо взаимодействующие части должны знать друг о друге больше. По крайней мере, взаимно о своём (абстрактном) существовании в природе...


Пример?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Активные структуры данных
СообщениеДобавлено: Вторник, 13 Май, 2008 01:43 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8945
Откуда: Россия, Орёл
Вот я и попросил написать разбор типа обрабатываемого объекта в стиле двойной диспетчеризации, чтоб пример потом привести :-)
Есть два объекта, A и B. Нужно вычислить обработчик AxB. Первое вычисление идёт через виртуальную таблицу A. Затем A должен отфутболить обратно к B. Получается, что сообщение должно знать о существовании обрабатывающих его объектов. И вызывать соответствующий своему самому метод. Т.е. базовый интерфейс объектов-обработчиков должен включать абстрактные процедуры для каждого типа сообщений. Или что-то не так?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Активные структуры данных
СообщениеДобавлено: Вторник, 13 Май, 2008 08:24 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Илья Ермаков писал(а):
Есть два объекта, A и B. Нужно вычислить обработчик AxB. Первое вычисление идёт через виртуальную таблицу A. Затем A должен отфутболить обратно к B. Получается, что сообщение должно знать о существовании обрабатывающих его объектов. И вызывать соответствующий своему самому метод. Т.е. базовый интерфейс объектов-обработчиков должен включать абстрактные процедуры для каждого типа сообщений. Или что-то не так?


Похоже "что-то не так" в терминах. Если "двойная диспетчеризация" обязательно подразумевает "отфутболивание" (как в примере AVC), то безусловно этот механизм более статичен. Изначально я имел ввиду просто полиморфность относительно динамического типа аргумента (как в моем ответе AVC). В этом случае я не вижу никаких отличий от message bus, кроме большей декларативности и жесткости.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Активные структуры данных
СообщениеДобавлено: Вторник, 13 Май, 2008 12:01 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8945
Откуда: Россия, Орёл
Тогда я не понимаю. А как возможен в С++ динамический полиморфизм по типу аргумента? Пергрузка ведь разрешается на этапе компиляции... Всё, блин, уже забыл...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Активные структуры данных
СообщениеДобавлено: Вторник, 13 Май, 2008 19:00 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Илья Ермаков писал(а):
Тогда я не понимаю. А как возможен в С++ динамический полиморфизм по типу аргумента?


Прямой поддержки конечно нет (есть в других языках, насколько я знаю). Но можно реализовать (я сам такое когда-то делал именно для обработки динамических сообщений). Если использовать мой прототип "проверка типа в стиле оберон", то оно еще и работать будет очень быстро.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Активные структуры данных
СообщениеДобавлено: Вторник, 13 Май, 2008 22:09 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1313
Vlad писал(а):
Владимир Лось писал(а):
Ну теперь вернёмся к первому варианту... Так что же всё-таки такое "просто методы"?

Это методы, не фигурирующие в интерфейсе (не заявленные "сервером" и не потреблямые "клиентами").

А что для вас является превалирующим обстоятельством и причиной определения "просто методов" в классе?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Активные структуры данных
СообщениеДобавлено: Среда, 14 Май, 2008 17:30 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Владимир Лось писал(а):
Vlad писал(а):
Это методы, не фигурирующие в интерфейсе (не заявленные "сервером" и не потреблямые "клиентами").

А что для вас является превалирующим обстоятельством и причиной определения "просто методов" в классе?


Логическое объединение данных (стэйта) и работающих с ними методов. В подарок получаю более наглядный синтаксис.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Активные структуры данных
СообщениеДобавлено: Среда, 14 Май, 2008 19:57 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1313
Vlad писал(а):
Логическое объединение данных (стэйта) и работающих с ними методов. В подарок получаю более наглядный синтаксис.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Активные структуры данных
СообщениеДобавлено: Среда, 14 Май, 2008 20:43 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Владимир Лось писал(а):
Vlad писал(а):
Логическое объединение данных (стэйта) и работающих с ними методов. В подарок получаю более наглядный синтаксис.

Тогда чем совокупность "просто методов" по смыслу отличается от совокупности "не просто методов"?


Тем, что совокупность "просто методов" внутреннее дело "сервера", не имеет к интерфейсу никакого отношения.

Владимир Лось писал(а):
Вы имеете формально (и явно) "не объявленный" объект внутри уже имеющегося объекта...


Ничего такого я не имею.

Владимир Лось писал(а):
Получается, что это просто явное упущение в вашем дизайне... :twisted: - вы перенесли идеологию фортрана внутрь (и на уровень) отдельного класса...


Звучит злобно, но бессмысленно.

Владимир Лось писал(а):
Второе упущение из-за отсутсвия формального отпределения указанного Вами "объединения" - отсутствие явно объявленных правил и механизмов синхронизации доступа к "состоянию" со стороны как "просто методов", так и "непростых методов"...


Со стороны "непростых методов" все под контролем. А со стороны "просто методов" все на виду. Так что я не понимаю что такое страшное может скрываться за тремя точками.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Активные структуры данных
СообщениеДобавлено: Четверг, 15 Май, 2008 22:30 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1313
Vlad писал(а):
Тем, что совокупность "просто методов" внутреннее дело "сервера", не имеет к интерфейсу никакого отношения.

Мда?... А работают они со «стэйтами» не одной и той же сущности(-тей)?

Vlad писал(а):
Владимир Лось писал(а):
Вы имеете формально (и явно) "не объявленный" объект внутри уже имеющегося объекта...
Ничего такого я не имею.

Ну – воля Ваша! – я кажется уже начинаю понимать, что конкретно Вы - не имеете...

Vlad писал(а):
Звучит злобно, но бессмысленно.

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

Vlad писал(а):
Владимир Лось писал(а):
Второе упущение из-за отсутсвия формального отпределения указанного Вами "объединения" - отсутствие явно объявленных правил и механизмов синхронизации доступа к "состоянию" со стороны как "просто методов", так и "непростых методов"...

Со стороны "непростых методов" все под контролем. А со стороны "просто методов" все на виду. Так что я не понимаю что такое страшное может скрываться за тремя точками.

А мне не спокойно всё ж-таки (на основании предыдущих Ваши высказываний)... Не намекнёте ли на механизмы и подходы к обеспечению выделенных, в Ваших предложениях, понятий? - на уровне проектных решений, (условного) синтаксиса и семантики (кратенько и по-простенькому)...
И, кстати, некоторым образом принимая возможный ход Ваших мыслей, Вы случайно не перепутали местами куски выделенного мной текста в Вашем высказывании относительно "простых" и "НЕ простых" методов? :twisted:


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Активные структуры данных
СообщениеДобавлено: Пятница, 16 Май, 2008 01:56 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Владимир Лось писал(а):
Vlad писал(а):
Тем, что совокупность "просто методов" внутреннее дело "сервера", не имеет к интерфейсу никакого отношения.

Мда?... А работают они со «стэйтами» не одной и той же сущности(-тей)?


Нет. "Видимый" (клиентам) стэйт может не иметь ничего общего с "внутренним". По всем канонам АТД :) И "сущности" тоже в общем смысле могут быть не связаны. "Внешняя" сущность может быть представлена комбинацией "внутренних". Короче, кому я все это рассказываю? :) Это ж основы компонентного программирования. В частности принцип "один интерфейс, множество реализаций". Потроха реализации не могут иметь отношение к интерфейсу по определению. "Просто методы" присутствуют в потрохах просто в силу того, что с ними удобнее/читабельнее реализовывать потроха в рамках конкретного языка (C++). "Не просто методы" присутствуют на уровне проектных решений.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Активные структуры данных
СообщениеДобавлено: Пятница, 16 Май, 2008 22:54 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1313
Цитата:
Короче, кому я все это рассказываю?

«... Да он издевается над нами! ...» (с)ктототам :о)

Цитата:
По всем канонам АТД.

???????????????????????????????!!!!!

Цитата:
"Видимый" (клиентам) стэйт может не иметь ничего общего с "внутренним".
"Внешняя" сущность может быть представлена комбинацией "внутренних".
Это ж основы компонентного программирования.

Это – подходы к реализации проектных решений! Не дай Бог с таких «основ» людей программированию учить!

Цитата:
В частности принцип "один интерфейс, множество реализаций". Потроха реализации не могут иметь отношение к интерфейсу по определению. "Просто методы" присутствуют в потрохах просто в силу того, что с ними удобнее/читабельнее реализовывать потроха в рамках конкретного языка (C++). "Не просто методы" присутствуют на уровне проектных решений.

VLAD!
То, что вы с таким жаром отстаиваете, есть просто достаточно частный (и довольно примитивный) способ понимания «интерфейса», аки набора функций для внешних пользователей. В рамках подходов, озвученных мной, Ваш случай - это когда всё множество актов взаимодействия ограничивается (АРХИТЕКТУРНО и СПЕЦИАЛЬНО!) по одной функции на «предоставляемую функциональность». Но в реальных системах сущности взаимодействуют сложными последовательностями обменов. В рамках, отстаиваемого Вами, подхода НЕТ формальных способов фиксации стадий (шагов) обмена между клиентами и серверами (в общем смысле этих слов). И нет поддержки ни со стороны языков, ни со стороны системы времени исполнения за правильностью хода такого взаимодействия! Ну разве что «поддерживается» ворохом диаграмм в доках сопровождения и соглашениями по наименованию «не просто методов»... Или Вы будете вынужденно изобретать «стэйтлесс» варианты взаимодействия... И чем это от не ООП вариантов реализаций отличаться будет? (потому я и упомянул «фортрановские подходы»).

А то, про что Вы описываете как «принцип "один интерфейс, множество реализаций"» - не есть сам принцип, а – языковый способ реализации. И он вынужденно «выпячен» на первые роли именно в силу давления подхода «один вызов функции(метода) – одна транзакция(получение результатов функциональности)». Именно в силу отсутствия поддержки и «слежения» за правильностью О_П_И_С_А_Н_Н_О_Г_О (НА ЯЗЫКЕ РЕАЛИЗАЦИИ) ПРОТОКОЛА обмена между сущностями («динамической» части описания)!
А будут у нас такие возможности – нам и док значительно меньше будет нужно – всё из текста программы будет автоматом выводиться! Это при традиционном понятии интерфейса, мы не можем оценить по тексту программы в нужной ли последовательности производится вызов тех или иных методов. А, при наличии формального описания протокола обмена, мы даже «скелеты» функций(методов) реализации протокола можем «заказывать» у среды разработки (а не просто «получение списка открытых методов и свойств»)!... Или – наоборот – требовать от среды анализа исходников на предмет соответствия протоколам...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Активные структуры данных
СообщениеДобавлено: Пятница, 16 Май, 2008 23:37 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Владимир Лось писал(а):
А, при наличии формального описания протокола обмена, мы даже «скелеты» функций(методов) реализации протокола можем «заказывать» у среды разработки (а не просто «получение списка открытых методов и свойств»)!... Или – наоборот – требовать от среды анализа исходников на предмет соответствия протоколам...


В огороде бузина, в а Киеве дядька :) Моей тезис "метод - это еще не интерфейс" относился исключительно к реализации "полиморфности по динамическому типу аргумента" (и ее критике), как более высокоуровневой концепции по сравнению с message bus. Вы же говорите о еще более высокоуровневой концепции "описания протокола обмена". Тема безусловно интересная, но относящаяся к изначальной только постольку поскольку (разве что как дальнейшее ее развитие).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Активные структуры данных
СообщениеДобавлено: Суббота, 17 Май, 2008 22:54 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1313
Vlad писал(а):
В огороде бузина, в а Киеве дядька :) Моей тезис "метод - это еще не интерфейс" относился исключительно к реализации "полиморфности по динамическому типу аргумента" (и ее критике), как более высокоуровневой концепции по сравнению с message bus. Вы же говорите о еще более высокоуровневой концепции "описания протокола обмена". Тема безусловно интересная, но относящаяся к изначальной только постольку поскольку (разве что как дальнейшее ее развитие).

Вот именно! Верно вы всё понимаете! А темы - непосредственно и тесно связаны. Проосто Вы, почему-то, упорно упёрлись в один из аспектов описания и представления "интерфейсов" и начисто не желаете "за угол заглянуть"... Удивительно даже!


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 54 ]  На страницу Пред.  1, 2, 3

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2018, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB