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. Почему бы просто не запрашивать соотв. объект через функцию и не проверять его на NIL.
Делаем: VAR msg: M.GetInterfaceMsg; obj.HandleMsg(msg). |
Автор: | Илья Ермаков [ Воскресенье, 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/ |