OberonCore
https://forum.oberoncore.ru/

Активные структуры данных
https://forum.oberoncore.ru/viewtopic.php?f=6&t=975		 Страница 3 из 3
Автор:  Vlad [ Вторник, 13 Май, 2008 01:12 ]
Заголовок сообщения:  Re: Активные структуры данных
Илья Ермаков писал(а):
И более статичный... Ибо взаимодействующие части должны знать друг о друге больше. По крайней мере, взаимно о своём (абстрактном) существовании в природе...


Пример?
Автор:  Илья Ермаков [ Вторник, 13 Май, 2008 01:43 ]
Заголовок сообщения:  Re: Активные структуры данных
Вот я и попросил написать разбор типа обрабатываемого объекта в стиле двойной диспетчеризации, чтоб пример потом привести :-)
Есть два объекта, A и B. Нужно вычислить обработчик AxB. Первое вычисление идёт через виртуальную таблицу A. Затем A должен отфутболить обратно к B. Получается, что сообщение должно знать о существовании обрабатывающих его объектов. И вызывать соответствующий своему самому метод. Т.е. базовый интерфейс объектов-обработчиков должен включать абстрактные процедуры для каждого типа сообщений. Или что-то не так?
Автор:  Vlad [ Вторник, 13 Май, 2008 08:24 ]
Заголовок сообщения:  Re: Активные структуры данных
Илья Ермаков писал(а):
Есть два объекта, A и B. Нужно вычислить обработчик AxB. Первое вычисление идёт через виртуальную таблицу A. Затем A должен отфутболить обратно к B. Получается, что сообщение должно знать о существовании обрабатывающих его объектов. И вызывать соответствующий своему самому метод. Т.е. базовый интерфейс объектов-обработчиков должен включать абстрактные процедуры для каждого типа сообщений. Или что-то не так?


Похоже "что-то не так" в терминах. Если "двойная диспетчеризация" обязательно подразумевает "отфутболивание" (как в примере AVC), то безусловно этот механизм более статичен. Изначально я имел ввиду просто полиморфность относительно динамического типа аргумента (как в моем ответе AVC). В этом случае я не вижу никаких отличий от message bus, кроме большей декларативности и жесткости.
Автор:  Илья Ермаков [ Вторник, 13 Май, 2008 12:01 ]
Заголовок сообщения:  Re: Активные структуры данных
Тогда я не понимаю. А как возможен в С++ динамический полиморфизм по типу аргумента? Пергрузка ведь разрешается на этапе компиляции... Всё, блин, уже забыл...
Автор:  Vlad [ Вторник, 13 Май, 2008 19:00 ]
Заголовок сообщения:  Re: Активные структуры данных
Илья Ермаков писал(а):
Тогда я не понимаю. А как возможен в С++ динамический полиморфизм по типу аргумента?


Прямой поддержки конечно нет (есть в других языках, насколько я знаю). Но можно реализовать (я сам такое когда-то делал именно для обработки динамических сообщений). Если использовать мой прототип "проверка типа в стиле оберон", то оно еще и работать будет очень быстро.
Автор:  Wlad [ Вторник, 13 Май, 2008 22:09 ]
Заголовок сообщения:  Re: Активные структуры данных
Vlad писал(а):
Владимир Лось писал(а):
Ну теперь вернёмся к первому варианту... Так что же всё-таки такое "просто методы"?

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

А что для вас является превалирующим обстоятельством и причиной определения "просто методов" в классе?
Автор:  Vlad [ Среда, 14 Май, 2008 17:30 ]
Заголовок сообщения:  Re: Активные структуры данных
Владимир Лось писал(а):
Vlad писал(а):
Это методы, не фигурирующие в интерфейсе (не заявленные "сервером" и не потреблямые "клиентами").

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


Логическое объединение данных (стэйта) и работающих с ними методов. В подарок получаю более наглядный синтаксис.
Автор:  Wlad [ Среда, 14 Май, 2008 19:57 ]
Заголовок сообщения:  Re: Активные структуры данных
Vlad писал(а):
Логическое объединение данных (стэйта) и работающих с ними методов. В подарок получаю более наглядный синтаксис.

Тогда чем совокупность "просто методов" по смыслу отличается от совокупности "не просто методов"?
Вы имеете формально (и явно) "не объявленный" объект внутри уже имеющегося объекта...
Получается, что это просто явное упущение в вашем дизайне... :twisted: - вы перенесли идеологию фортрана внутрь (и на уровень) отдельного класса...
Второе упущение из-за отсутсвия формального отпределения указанного Вами "объединения" - отсутствие явно объявленных правил и механизмов синхронизации доступа к "состоянию" со стороны как "просто методов", так и "непростых методов"...
Автор:  Vlad [ Среда, 14 Май, 2008 20:43 ]
Заголовок сообщения:  Re: Активные структуры данных
Владимир Лось писал(а):
Vlad писал(а):
Логическое объединение данных (стэйта) и работающих с ними методов. В подарок получаю более наглядный синтаксис.

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


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

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


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

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


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

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


Со стороны "непростых методов" все под контролем. А со стороны "просто методов" все на виду. Так что я не понимаю что такое страшное может скрываться за тремя точками.
Автор:  Wlad [ Четверг, 15 Май, 2008 22:30 ]
Заголовок сообщения:  Re: Активные структуры данных
Vlad писал(а):
Тем, что совокупность "просто методов" внутреннее дело "сервера", не имеет к интерфейсу никакого отношения.

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

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

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

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

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

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

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

А мне не спокойно всё ж-таки (на основании предыдущих Ваши высказываний)... Не намекнёте ли на механизмы и подходы к обеспечению выделенных, в Ваших предложениях, понятий? - на уровне проектных решений, (условного) синтаксиса и семантики (кратенько и по-простенькому)...
И, кстати, некоторым образом принимая возможный ход Ваших мыслей, Вы случайно не перепутали местами куски выделенного мной текста в Вашем высказывании относительно "простых" и "НЕ простых" методов? :twisted:
Автор:  Vlad [ Пятница, 16 Май, 2008 01:56 ]
Заголовок сообщения:  Re: Активные структуры данных
Владимир Лось писал(а):
Vlad писал(а):
Тем, что совокупность "просто методов" внутреннее дело "сервера", не имеет к интерфейсу никакого отношения.

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


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

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

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

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

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

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

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

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

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


В огороде бузина, в а Киеве дядька :) Моей тезис "метод - это еще не интерфейс" относился исключительно к реализации "полиморфности по динамическому типу аргумента" (и ее критике), как более высокоуровневой концепции по сравнению с message bus. Вы же говорите о еще более высокоуровневой концепции "описания протокола обмена". Тема безусловно интересная, но относящаяся к изначальной только постольку поскольку (разве что как дальнейшее ее развитие).
Автор:  Wlad [ Суббота, 17 Май, 2008 22:54 ]
Заголовок сообщения:  Re: Активные структуры данных
Vlad писал(а):
В огороде бузина, в а Киеве дядька :) Моей тезис "метод - это еще не интерфейс" относился исключительно к реализации "полиморфности по динамическому типу аргумента" (и ее критике), как более высокоуровневой концепции по сравнению с message bus. Вы же говорите о еще более высокоуровневой концепции "описания протокола обмена". Тема безусловно интересная, но относящаяся к изначальной только постольку поскольку (разве что как дальнейшее ее развитие).

Вот именно! Верно вы всё понимаете! А темы - непосредственно и тесно связаны. Проосто Вы, почему-то, упорно упёрлись в один из аспектов описания и представления "интерфейсов" и начисто не желаете "за угол заглянуть"... Удивительно даже!
Страница 3 из 3 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/