OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 19 Март, 2024 08:49

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




Начать новую тему Ответить на тему  [ Сообщений: 101 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.
Автор Сообщение
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Воскресенье, 02 Сентябрь, 2012 17:52 

Зарегистрирован: Четверг, 23 Апрель, 2009 18:01
Сообщения: 219
Илья, спасибо за сообщения. Интересная тема и хорошее объяснение.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Воскресенье, 02 Сентябрь, 2012 18:24 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Илья Ермаков писал(а):
К нам в руки попал объект obj. Мы хотим запросить у него интерфейс Interface.
Делаем:
VAR
msg: M.GetInterfaceMsg;
obj.HandleMsg(msg).
Почему бы просто не запрашивать соотв. объект через функцию и не проверять его на NIL.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Воскресенье, 02 Сентябрь, 2012 18:29 
Модератор
Аватара пользователя

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Воскресенье, 02 Сентябрь, 2012 23:42 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Илья Ермаков писал(а):
Если при развитии системы появляются новые интерфейсы, которыми могут располагать уже бывшие типы, то введение будет болезненным.
Да, тут как с любой статической фиксацией какого-то знания.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Воскресенье, 02 Сентябрь, 2012 23:57 

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


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

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


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Понедельник, 03 Сентябрь, 2012 08:52 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Александр Шостак писал(а):
Илья, а почему Reader и Writer не имеют PosOf, учитывая, что позиция в них будет храниться всегда и что, особенно для Reader, это естественно иметь доступ на чтение к позиции. Скажем, анализатор текста просто читает текст (Reader), но запоминает позиции лексем.


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


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Info21 писал(а):
По-возможности нужно фиксировать статически.


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Понедельник, 03 Сентябрь, 2012 13:30 

Зарегистрирован: Четверг, 23 Апрель, 2009 18:01
Сообщения: 219
Цитата:
Если PosOf перенести из Slider'а в Reader, то придется перенести его и в Writer с тем же кодом. Получится дублирование - один из источников проблем.

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Понедельник, 03 Сентябрь, 2012 14:24 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Не стоит ли Слайдер привязать к Райдеру вместо Носителя?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Понедельник, 03 Сентябрь, 2012 14:50 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Александр Шостак писал(а):
А если не переносить, то большинству чтецов, которым просто нужна позиция (и не важно, кольцевой буфер это или нет, кол-во считанный байт хранить-то можно), нужно будет передавать и Slider, при чём вовсе не для изменения этой самой позиции. Или я что-то не так понял?

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Понедельник, 03 Сентябрь, 2012 14:52 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Info21 писал(а):
Не стоит ли Слайдер привязать к Райдеру вместо Носителя?


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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Понедельник, 03 Сентябрь, 2012 17:31 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Илья Ермаков писал(а):
... сделал невозможным достать через Райдер носитель или слайдер.
Про носитель понятно.
Но почему "или слайдер"?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Понедельник, 03 Сентябрь, 2012 20:29 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
У меня было целесообразно явно подчёркивать однопроходность алгоритма. Т.е. если он просит только Reader - значит однопроходный, не бегает по последовательности. А если просит Slider - значит, будет бегать.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Понедельник, 03 Сентябрь, 2012 22:07 

Зарегистрирован: Четверг, 23 Апрель, 2009 18:01
Сообщения: 219
А как однопроходнсть алгоритма согласуется с LookBytes в Reader? Это, ведь, фактически, чтение без изменения позиции (аналог Peek).


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Александр Шостак писал(а):
А как однопроходнсть алгоритма согласуется с LookBytes в Reader? Это, ведь ...
У меня тоже впечатление, что, ну, как обычно, перемудрено чуть-чуть :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Вторник, 04 Сентябрь, 2012 08:06 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Александр Шостак писал(а):
А как однопроходнсть алгоритма согласуется с LookBytes в Reader? Это, ведь, фактически, чтение без изменения позиции (аналог Peek).


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Вторник, 04 Сентябрь, 2012 08:22 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Info21 писал(а):
У меня тоже впечатление, что, ну, как обычно, перемудрено чуть-чуть :)


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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моделирование интерфейсов
СообщениеДобавлено: Вторник, 04 Сентябрь, 2012 11:29 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
А. Понятно.

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

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


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

Зарегистрирован: Четверг, 23 Апрель, 2009 18:01
Сообщения: 219
Цитата:
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?


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

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


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

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


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

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