OberonCore

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

Почему бы просто не запрашивать соотв. объект через функцию и не проверять его на NIL.

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

Да, тут как с любой статической фиксацией какого-то знания.

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

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

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

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

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

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

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

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

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

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

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

Про носитель понятно.
Но почему "или слайдер"?

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

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

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

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

В теории трансляции это называется 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?