OberonCore
https://forum.oberoncore.ru/

Моделирование интерфейсов
https://forum.oberoncore.ru/viewtopic.php?f=29&t=3640
Страница 5 из 6

Автор:  Александр Шостак [ Воскресенье, 02 Сентябрь, 2012 17:52 ]
Заголовок сообщения:  Re: Моделирование интерфейсов

Илья, спасибо за сообщения. Интересная тема и хорошее объяснение.

Автор:  Info21 [ Воскресенье, 02 Сентябрь, 2012 18:24 ]
Заголовок сообщения:  Re: Моделирование интерфейсов

Илья Ермаков писал(а):
К нам в руки попал объект obj. Мы хотим запросить у него интерфейс Interface.
Делаем:
VAR
msg: M.GetInterfaceMsg;
obj.HandleMsg(msg).
Почему бы просто не запрашивать соотв. объект через функцию и не проверять его на NIL.

Автор:  Илья Ермаков [ Воскресенье, 02 Сентябрь, 2012 18:29 ]
Заголовок сообщения:  Re: Моделирование интерфейсов

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

Автор:  Info21 [ Воскресенье, 02 Сентябрь, 2012 23:42 ]
Заголовок сообщения:  Re: Моделирование интерфейсов

Илья Ермаков писал(а):
Если при развитии системы появляются новые интерфейсы, которыми могут располагать уже бывшие типы, то введение будет болезненным.
Да, тут как с любой статической фиксацией какого-то знания.

По-возможности нужно фиксировать статически.

Автор:  Александр Шостак [ Воскресенье, 02 Сентябрь, 2012 23:57 ]
Заголовок сообщения:  Re: Моделирование интерфейсов

Илья, а почему Reader и Writer не имеют PosOf, учитывая, что позиция в них будет храниться всегда и что, особенно для Reader, это естественно иметь доступ на чтение к позиции. Скажем, анализатор текста просто читает текст (Reader), но запоминает позиции лексем.

Автор:  Дмитрий Грачёв [ Понедельник, 03 Сентябрь, 2012 06:50 ]
Заголовок сообщения:  Re: Моделирование интерфейсов

Александр Шостак писал(а):
Илья, а почему Reader и Writer не имеют PosOf, учитывая, что позиция в них будет храниться всегда и что, особенно для Reader, это естественно иметь доступ на чтение к позиции. Скажем, анализатор текста просто читает текст (Reader), но запоминает позиции лексем.


Если PosOf перенести из Slider'а в Reader, то придется перенести его и в Writer с тем же кодом. Получится дублирование - один из источников проблем.
Или вы про поле? Поле будет в реализации, а Илья описал только интерфейсы, которые про реализацию ничего не знают.

Автор:  Илья Ермаков [ Понедельник, 03 Сентябрь, 2012 08:52 ]
Заголовок сообщения:  Re: Моделирование интерфейсов

Александр Шостак писал(а):
Илья, а почему Reader и Writer не имеют PosOf, учитывая, что позиция в них будет храниться всегда и что, особенно для Reader, это естественно иметь доступ на чтение к позиции. Скажем, анализатор текста просто читает текст (Reader), но запоминает позиции лексем.


Ну, я же про это пояснил выше. В том и дело, что бывают носители данных с однократным чтением (кольцевой буфер, принимающий данные из сети, например). Или передаём алгоритму данные только для однократного чтения/записи в указанной позиции. Затем и отделяем Slider.

Автор:  Илья Ермаков [ Понедельник, 03 Сентябрь, 2012 09:01 ]
Заголовок сообщения:  Re: Моделирование интерфейсов

Info21 писал(а):
По-возможности нужно фиксировать статически.


Безусловно.
Тут и противоречия-то нет: делаем статически функции, но когда в какой-момент понадобилось расширение за рамки старого скелета, то заложенный заранее HandleMsg вступает в дело...

Автор:  Александр Шостак [ Понедельник, 03 Сентябрь, 2012 13:30 ]
Заголовок сообщения:  Re: Моделирование интерфейсов

Цитата:
Если PosOf перенести из Slider'а в Reader, то придется перенести его и в Writer с тем же кодом. Получится дублирование - один из источников проблем.

А если не переносить, то большинству чтецов, которым просто нужна позиция (и не важно, кольцевой буфер это или нет, кол-во считанный байт хранить-то можно), нужно будет передавать и Slider, при чём вовсе не для изменения этой самой позиции. Или я что-то не так понял?

P.S. Из интерфейса не понятно, как происходит работа с ошибками, не полным количеством реально прочитанных/записанных байтов из запрошенных.

Автор:  Info21 [ Понедельник, 03 Сентябрь, 2012 14:24 ]
Заголовок сообщения:  Re: Моделирование интерфейсов

Не стоит ли Слайдер привязать к Райдеру вместо Носителя?

Автор:  Илья Ермаков [ Понедельник, 03 Сентябрь, 2012 14:50 ]
Заголовок сообщения:  Re: Моделирование интерфейсов

Александр Шостак писал(а):
А если не переносить, то большинству чтецов, которым просто нужна позиция (и не важно, кольцевой буфер это или нет, кол-во считанный байт хранить-то можно), нужно будет передавать и Slider, при чём вовсе не для изменения этой самой позиции. Или я что-то не так понял?

Чтецы у меня обычно считают относительную позицию сами. В этом ещё помогает поле Reader.read (полного доступа, как Files.File.eof), в котором накапливается количество считанных. Я его убрал в примере для простоты.
Кроме того, есть Reader.Available() - сколько доступно впереди.

Автор:  Илья Ермаков [ Понедельник, 03 Сентябрь, 2012 14:52 ]
Заголовок сообщения:  Re: Моделирование интерфейсов

Info21 писал(а):
Не стоит ли Слайдер привязать к Райдеру вместо Носителя?


В каком смысле привязать? Чтобы у райдера можно было запросить слайдер? Тогда я выше как раз пояснял, что сделал невозможным достать через Райдер носитель или слайдер. Чтобы можно было контролировать функции, которыми пользуются компоненты. Если я кому-то не дал Slider, то он никак его не получит.

В плане же привязки реализационной - то, как я выше тоже писал, слайдер вообще живёт в единственном экземпляре для всех Носителей данного типа, ибо состояния он не имеет (курьера ему передаём при вызове Pos/SetPos).

Автор:  Info21 [ Понедельник, 03 Сентябрь, 2012 17:31 ]
Заголовок сообщения:  Re: Моделирование интерфейсов

Илья Ермаков писал(а):
... сделал невозможным достать через Райдер носитель или слайдер.
Про носитель понятно.
Но почему "или слайдер"?

Автор:  Илья Ермаков [ Понедельник, 03 Сентябрь, 2012 20:29 ]
Заголовок сообщения:  Re: Моделирование интерфейсов

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

Также есть такие реализации носителя, когда Reader "пожирает" данные - и второй раз они просто недоступны. Т.е. позиционирование для курьера не имеет смысла.

Автор:  Александр Шостак [ Понедельник, 03 Сентябрь, 2012 22:07 ]
Заголовок сообщения:  Re: Моделирование интерфейсов

А как однопроходнсть алгоритма согласуется с LookBytes в Reader? Это, ведь, фактически, чтение без изменения позиции (аналог Peek).

Автор:  Info21 [ Вторник, 04 Сентябрь, 2012 07:43 ]
Заголовок сообщения:  Re: Моделирование интерфейсов

Александр Шостак писал(а):
А как однопроходнсть алгоритма согласуется с LookBytes в Reader? Это, ведь ...
У меня тоже впечатление, что, ну, как обычно, перемудрено чуть-чуть :)

Автор:  Илья Ермаков [ Вторник, 04 Сентябрь, 2012 08:06 ]
Заголовок сообщения:  Re: Моделирование интерфейсов

Александр Шостак писал(а):
А как однопроходнсть алгоритма согласуется с LookBytes в Reader? Это, ведь, фактически, чтение без изменения позиции (аналог Peek).


В теории трансляции это называется look-ahead-scanner, это всё равно однопроходность... Просто доп. удобство - не держать буфер для порции, которая уже прочитана, но ещё нужна "в поле зрения" для анализа.

Автор:  Илья Ермаков [ Вторник, 04 Сентябрь, 2012 08:22 ]
Заголовок сообщения:  Re: Моделирование интерфейсов

Info21 писал(а):
У меня тоже впечатление, что, ну, как обычно, перемудрено чуть-чуть :)


Дмитрий Грачёв своим вопросом вынудил привести пример из свежего, неокончательного, что меняется пока что вместе с проектами. Что-то, возможно, "обобьётся". Я сам колебался насчёт этих слайдеров, но там есть интересные контексты в моих модулях, которые меня склонили попробовать. Если бы я привёл примеры, как это используется, то было бы что обсуждать, на пока я не могу это сделать.

Поэтому воспринимайте выше приведённый пример как демонстрацию "как сделать вот такое разбиение на интерфейсы", без критики самого разбиения. Оно пробуется :)

Автор:  Info21 [ Вторник, 04 Сентябрь, 2012 11:29 ]
Заголовок сообщения:  Re: Моделирование интерфейсов

А. Понятно.

Идея, видимо, разумная (в условиях конкретной задачи).
А реализация пробная, оттого.

Понятно, вопросов нет.

Автор:  Александр Шостак [ Вторник, 04 Сентябрь, 2012 19:57 ]
Заголовок сообщения:  Re: Моделирование интерфейсов

Цитата:
look-ahead-scanner

Я не спорю, но подглядывание вперёд на произвольное число байт = многократное чтение. Возьмите массив на 1 МБ, далее заглядывайте на 1, 2, 3, ...n байтов поочерёдно. Чем не чтение? :). Следовательно все чтецы должны реализовать промежуточный динамический буфер а-ля POINTER TO ARRAY OF BYTE.

Вы не подумайте, что я что-то критикую. Просто я, как и авторы многочисленных каркасов, а также студенты (отсылка на ваше сообщение) первый раз, когда писал свой каркас, сделал один абстрактный TAbstractFile. Потом немного познакомился с Carrier-Rider-Mapper, затем диссертация Шиперски (Carrier - Link - Mapper), а теперь вот ваш вариант. И каждый раз всё меняется на корню. У Шиперски, например, позиционируемые потоки - дочерние от общих потоков. У вас - скользящие объекты выделены отдельно. Ну и обычная рутина: базовый абстрактный набор необходимых функций, обработка ошибок, обратная связь.

Вот, например, Available. Если вдруг подпрограмма будет использовать это поле, то жди беды. В поточных данных количество доступных данных бывает чаще всего неизвестно или обновляется быстро маленькими порциями. В итоге что возвращать? 0? Можно ли считать Available = 0 концом файла?

Мой старый вариант абстрактного класса файла без разделения на носителей и курьеров: http://pastebin.com/JuYaKk3N. Там были свойства HasKnownSize и SizeIsConst. А что у вас возвращают носители с неизвестным размером? Или там везде HALT?

Страница 5 из 6 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/