Здравствуйте, WolfHound, Вы писали:

WH>Именно. Тебе пора наконец понять что оберон создавали простые смертные люди которые тоже могут ошибаться. И в данном случае они ошиблись.

Что за бред...

Здравствуйте, WolfHound, Вы писали:

WH>Вот и я спрашиваю что мешало великим гениям создавшим черную коробку правильно спроектировать интерфейсы системы?

Ы-ы-ы? Извините, но я Вас не понимаю... Вы о чём?

Здравствуйте, Сергей Губанов, Вы писали:

WH>>Именно. Тебе пора наконец понять что оберон создавали простые смертные люди которые тоже могут ошибаться. И в данном случае они ошиблись.
СГ>Что за бред...
Бред это то что спроектрировали обероновци, а также вера в их непогрешимость.
Ответь на вопрос чем файл отличается от куска памяти с точки зрения абстрактного читателя/писателя? Или чем сокет отличается от сжимающего/шифрующего/кодирующего в base64 потока или их комбинации?

Сергей Губанов wrote:
> C>Это я к тому, что эта архитектура ввода-вывода не подходит для других
> C>целей кроме чтения файлов.
> Архитектура говорите не подходит, ну-ну...
Точнее ее отсутствие.

> C> А вот потоки прекрасно подходят.
> И что же может помешать их использовать?
Ну так вы же говорите, что Carrier-Rider-Mapper — рулез.

Кстати! Вспомнил одну такую библиотеку с подобной идеологией. VTK
(Visualization TooloKit) называется. Там есть DataSource, Actor и Mapper.

DataSource является источником данных (треугольников, точек и т.п.),
Actor является объектом на сцене, с которыми можно делать действия, а
Mapper управляет отображениеми объектов на реальное устройство. В теории
выглядит все красиво, а на практике — пользоваться очень сложно и неудобно.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Сергей Губанов, Вы писали:

WH>>>Именно. Тебе пора наконец понять что оберон создавали простые смертные люди которые тоже могут ошибаться. И в данном случае они ошиблись.

Конечно, ошибаются! И наверняка (я не в курсе обероновских вещей) они допускали ошибки или просчеты, однако в данном случае вроде все имеет право на жизнь.

СГ>>Что за бред...

Нет, нет, совсем не бред! Я уверяю тебя, Сергей, WolfHound прав, люди могут ошибаться.

WH>Бред это то что спроектрировали обероновци,

Да нормально спроектировали. В данном случае Carrier-Rider-Mapper они реализовали для работы с файлами, возможно (я не в курсе обероновских вещей), есть реализации и для работы с сетью, куском памяти или чего-то еще.

WH>а также вера в их непогрешимость.
WH>Ответь на вопрос чем файл отличается от куска памяти с точки зрения абстрактного читателя/писателя? Или чем сокет отличается от сжимающего/шифрующего/кодирующего в base64 потока или их комбинации?

Ну тут не совсем абстрактный читатель/писатель, а вполне конкретный — для работы с файлами. Еще раз оговорюсь, я не вижу причин, считать, что паттерн Carrier-Rider-Mapper не подходит для этой задачи. А как уж там сделали оберонисты, ввели достаточно высокий уровень абстракции или забыли(забили?), ну не все ли равно.

ie wrote:
> Ну тут не совсем абстрактный читатель/писатель, а вполне конкретный —
> для работы с файлами.
А почему бы тогда сразу не сделать класс FileReader и не заморачиваться
со всей архитектурой?

Здравствуйте, ie, Вы писали:

ie>Да нормально спроектировали. В данном случае Carrier-Rider-Mapper они реализовали для работы с файлами, возможно (я не в курсе обероновских вещей), есть реализации и для работы с сетью, куском памяти или чего-то еще.
Вот именно что с файлами и только с файлами.

WH>>Ответь на вопрос чем файл отличается от куска памяти с точки зрения абстрактного читателя/писателя? Или чем сокет отличается от сжимающего/шифрующего/кодирующего в base64 потока или их комбинации?

ie>Ну тут не совсем абстрактный читатель/писатель, а вполне конкретный — для работы с файлами. Еще раз оговорюсь, я не вижу причин, считать, что паттерн Carrier-Rider-Mapper не подходит для этой задачи. А как уж там сделали оберонисты, ввели достаточно высокий уровень абстракции или забыли(забили?), ну не все ли равно.
А смысл тогда во всей этой архитектуре если всеравно все гвоздями прибито к файлу?
Всетки ответь на мой вопрос.

Здравствуйте, WolfHound, Вы писали:

WH>Бред это то что спроектрировали обероновци, а также вера в их непогрешимость.

Ещё раз:

WH>Ответь на вопрос чем файл отличается от куска памяти с точки зрения абстрактного читателя/писателя? Или чем сокет отличается от сжимающего/шифрующего/кодирующего в base64 потока или их комбинации?

А я Вам и не показывал никакого абстрактного считывателя и записывателя! А то что в коде есть выражение ABSTRACT RECORD — так то просто ключевые слова в языке Component Pascal. Я не виноват, что они у Вас в голове чего-то закоротили на абстрактную тему.

Обобщённый байтовый считыватель я указал вот в этом сообщении:
http://www.rsdn.ru/Forum/Message.aspx?mid=1928427&only=1

Автор: Сергей Губанов
Дата: 31.05.06

DEFINITION IO;

  TYPE
    Reader* = POINTER TO ABSTRACT RECORD
      (r: Reader) ReadBytes (OUT buf: ARRAY OF BYTE; offset, count: INTEGER): INTEGER, NEW, ABSTRACT;
    END;

    RandomReader* = POINTER TO ABSTRACT RECORD (Reader)
      (r: Reader) Pos (): INTEGER, NEW, ABSTRACT;
      (r: Reader) SetPos (pos: INTEGER), NEW, ABSTRACT;
    END;
 
   ...

END IO.

и к ABSTRACT-считывателям Files.Reader и TextModels.Reader ни какого отношения он не имеет. Но его конкретная реализация может являться обёрткой над ними, что я и продемонстрировал в том же сообщении написав модуль MyIOFileWrapper.

Здравствуйте, Cyberax, Вы писали:

>> Ну тут не совсем абстрактный читатель/писатель, а вполне конкретный —
>> для работы с файлами.

C>А почему бы тогда сразу не сделать класс FileReader и не заморачиваться
C>со всей архитектурой?


FileReader задаёт отношение 1:1 = (один носитель информации) : (один пользователь)

Carrier-Rider задаёт отношение 1:N = (один носитель информации) : (N пользователей)

Здравствуйте, WolfHound, Вы писали:

WH>А смысл тогда во всей этой архитектуре если всеравно все гвоздями прибито к файлу?

Вы с Cyberax одни и те же вопросы наперегонки задаёте:

http://www.rsdn.ru/Forum/Message.aspx?mid=1929001&only=1

Автор: Сергей Губанов
Дата: 31.05.06

У одного файла одновременно могут быть много независимых Rider-ов, т.е. разделение Carrier-Rider носителя информации от доставителей этой информации есть констатация 1:N отношения между "сервером" и "клиентами".

Сергей Губанов wrote:
> C>А почему бы тогда сразу не сделать класс FileReader и не заморачиваться
> C>со всей архитектурой?
> FileReader задаёт отношение 1:1 = (один носитель информации) : (один
> пользователь)
> Carrier-Rider задаёт отношение 1:N = (один носитель информации) : (N
> пользователей)
Во-первых, делает это он (как похоже все в Обероне) криво. Как,
например, синхронизировать доступ? Уж пусть лучше этим файловая система
займется.

Во-вторых:

BufferedTeeInputStream tee=new BufferedTeeInputStream(stream);
InputStream one=tee.getOutlet(0);
InputStream two=tee.getOutlet(1);
InputStream three=tee.getOutlet(2);

Здравствуйте, Cyberax, Вы писали:

>> C> А вот потоки прекрасно подходят.
>> И что же может помешать их использовать?
C>Ну так вы же говорите, что Carrier-Rider-Mapper — рулез.

Carrier-Rider-Mapper — это паттерн проектирования, а InputStream/OutputStream — это классы (интерфейсы) из библиотеки. Одно другому не мешает.

Здравствуйте, Cyberax, Вы писали:

C>Во-первых, делает это он (как похоже все в Обероне) криво.



C>Как, например, синхронизировать доступ?

Могу научить, если Вы не знаете.

C>Во-вторых:
C>

C>BufferedTeeInputStream tee=new BufferedTeeInputStream(stream);
C>InputStream one=tee.getOutlet(0);
C>InputStream two=tee.getOutlet(1);
C>InputStream three=tee.getOutlet(2);
C>

Ха-ха-ха, да после этого — это я должен ехидно поинтересоваться у Вас с какого это перепуга BufferedTeeInputStream является и Rider-ом и Carrier-ом одновременно!!!

Сергей Губанов wrote:
> C>Как, например, синхронизировать доступ?
> Могу научить, если Вы не знаете.
Только не надо про активные объекты. Они не помогут — нужно
синхронизировать доступ между вызовами объекта с файлом.

> C>BufferedTeeInputStream tee=new BufferedTeeInputStream(stream);
> C>InputStream one=tee.getOutlet(0);
> C>InputStream two=tee.getOutlet(1);
> C>InputStream three=tee.getOutlet(2);
> Ха-ха-ха, да после этого — это я должен ехидно поинтересоваться у Вас с
> какого это перепуга BufferedTeeInputStream является и Rider-ом и
> Carrier-ом одновременно!!!
Это просто способ обеспечить 1:N разветвление в идеологии потоков.
BufferedTeeInputStream обеспечивает разветвление потока (т.е. является
T-коннектором, отсюда и название). Для поддержки forward only потоков
используется backlog-буффер (отсюда слово Buffered).

Здравствуйте, Сергей Губанов, Вы писали:

WH>>Ответь на вопрос чем файл отличается от куска памяти с точки зрения абстрактного читателя/писателя? Или чем сокет отличается от сжимающего/шифрующего/кодирующего в base64 потока или их комбинации?

СГ>А я Вам и не показывал никакого абстрактного считывателя и записывателя! А то что в коде есть выражение ABSTRACT RECORD — так то просто ключевые слова в языке Component Pascal. Я не виноват, что они у Вас в голове чего-то закоротили на абстрактную тему.
Синтаксис компонентного паскаля (не смотри на то что он очень плохо читается) я прекрасно понимаю.
Всетки ответь на мой вопрос. В данном случае абстракный читатель/писатьель это клиент Reader'а. Например некий код который читает картинку из файла. А потом вдруг понадобилось эту картинку прочитать из блоба или сокета...

СГ>и к ABSTRACT-считывателям Files.Reader и TextModels.Reader ни какого отношения он не имеет.
Почему? Ведь это яный косяк. Files.Reader имеет право на существование но он должен быть расширением IO.RandomReader.
А TextModels.Reader (я знаю что он абстрактный) должен быть реализован не над Files.Reader, а над IO.RandomReader или вобще над IO.Reader. Для того чтобы не писать одно и тоже для файлов и сокетов.

СГ>Но его конкретная реализация может являться обёрткой над ними, что я и продемонстрировал в том же сообщении написав модуль MyIOFileWrapper.
И что же мне плодить обертки над файлами, сокетами и черт знает чем еще. Переписывать TextModels, TextMappers, Stores,...
И все из-за того что оберонщики не умеют производить объектную декомпозицию?

Здравствуйте, Сергей Губанов, Вы писали:

СГ>У одного файла одновременно могут быть много независимых Rider-ов, т.е. разделение Carrier-Rider носителя информации от доставителей этой информации есть констатация 1:N отношения между "сервером" и "клиентами".
Скажем если взять винду и .НЕТ то Carrier это файловая система, Rider FileStream, а Mapper StreamReader.

        static void Main(string[] args)
        {
            string path = "test";
            using (Stream file1 = File.Open(path, FileMode.OpenOrCreate, FileAccess.Read, FileShare.Read))
            using (Stream file2 = File.Open(path, FileMode.OpenOrCreate, FileAccess.Read, FileShare.Read))
            using (Stream file3 = File.Open(path, FileMode.OpenOrCreate, FileAccess.Read, FileShare.Read))
            {
                Console.WriteLine(new StreamReader(file1).ReadToEnd());
                Console.WriteLine(new StreamReader(file2).ReadToEnd());
                Console.WriteLine(new StreamReader(file3).ReadToEnd());
            }
        }

Заметь StreamReader работает не с FileStream, а со Stream. А теперь объясни мне почему оберощики не додумались до такой простой вещи?

Здравствуйте, WolfHound, Вы писали:

WH> И что же мне плодить обертки над файлами, сокетами и черт знает чем еще.

Да. Эти обёртки и есть мапперы.

WH> Переписывать TextModels, TextMappers, Stores,...

Нет. Пользуйтесь мапперами.

WH>И все из-за того что оберонщики не умеют производить объектную декомпозицию?

Наоборот. Именно оберонщики как раз и изобрели декомпозицию Carrier-Rider-Mapper.

Связи между A.Reader и B.Reader, где A и B — разные модули, вообще говоря, нету.

Ведь модули А и В ничего друг о друге не знают (написаны разными производителями). Да и каждый из этих rider-ов специально спроектирован (заточен) именно только под свой тип Carrier-ов.

A.Carrier и B.Carrier — ну совсем разные carrier-ы и было бы очень странно если бы они имели в точности одинаковые rider-ы.

Производитель модуля С, желая подружить A.Reader и B.Reader с С.Reader должен написать реализацию C.Reader-а как объект агрегирующий объект типа А.Reader и как объект агрегирующий объект типа В.Reader, т.е. 2 обёртки над ними.

DEFINITION C;

  IMPORT A, B;
 
  TYPE

    ...

    Reader = POINTER TO ABSTRACT RECORD
      ...
    END;

  PROCEDURE NewReaderA (r: A.Reader): Reader; (* возвращает А-обёртку *)
  PROCEDURE NewReaderB (r: B.Reader): Reader; (* возвращает В-обёртку *)

    ...

END C.

Здравствуйте, Сергей Губанов, Вы писали:

WH>> Переписывать TextModels, TextMappers, Stores,...
СГ>Нет. Пользуйтесь мапперами.
Угу... мапперы на мапперы... переливаем из пустого в порожнее.

WH>>И все из-за того что оберонщики не умеют производить объектную декомпозицию?
СГ>Наоборот. Именно оберонщики как раз и изобрели декомпозицию Carrier-Rider-Mapper.
Обозвали всем извесный адаптер умным словом... действительно крутые ребята.

СГ>A.Carrier и B.Carrier — ну совсем разные carrier-ы и было бы очень странно если бы они имели в точности одинаковые rider-ы.
Вот возьмем к примеру файл, сокет и кусок памяти. Что у них общего? Правильно. Их можно использовать как поток байт. Следовательно у них должен быть общая часть интерфейса. Имя которой поток.
Далие исключим сокет. Что теперь общего? А то что по этим сущьностям можно перемещаться произвольным способом. Те имеем поток с произвольным доступом.
Причем поток это настолько фундаментальная штука что не внести его интерфейс в стандартную библиотеку рядом с какимнибудь Integer'ом просто верх недальновидности.

СГ>Производитель модуля С, желая подружить A.Reader и B.Reader с С.Reader должен написать реализацию C.Reader-а как объект агрегирующий объект типа А.Reader и как объект агрегирующий объект типа В.Reader, т.е. 2 обёртки над ними.
Это все понятно. Данный паттрен болие известен как адаптор.
Вот только зачем писать адапторы если можно подумать и обойтись без них?

Здравствуйте, WolfHound, Вы писали:

WH> Вот только зачем писать адапторы если можно подумать и обойтись без них?

Если у бинарного файла, сокета и кусока памяти и есть что-то общее, то это не значит что и у всего остального тоже будет что-то общее, что можно выразить синтаксически.

Например, у документа (TextModels.Model) или у формы (FormModels.Model) нет ничего общего ни друг с другом, ни с бинарным файлом, ни с сокетом, ни с куском памяти, что можно было бы выразить синтаксически. Их объединяет только общая идея — все они carrier-ы, т.е. носители информации. TextModels.Model — носитель букв написанных разными шрифтами и цветами и т.п., FormModels.Model — носитель визуальных контролов типа кнопок, полей ввода и т.п..

Carrier-ы могут быть самыми разнообразными, так что обобщенного класса всевозможных carrier-ов (и их rider-ов) написать на языке программирования один раз и навсегда — невозможно.

Кстати, в дополнение к предыдущим примерам, вот пример формы:

DEFINITION FormModels;

    IMPORT Containers, Models, Views;

    CONST
        maxViewSize = 36000000;
        minViewSize = 50800;

    TYPE
        Context = POINTER TO ABSTRACT RECORD (Models.Context)
            (c: Context) GetRect (OUT l, t, r, b: INTEGER), NEW, ABSTRACT;
            (c: Context) ThisModel (): Model, ABSTRACT
        END;

        Directory = POINTER TO ABSTRACT RECORD 
            (d: Directory) New (): Model, NEW, ABSTRACT
        END;

        Model = POINTER TO ABSTRACT RECORD (Containers.Model)
            (f: Model) Copy (VAR v: Views.View; dx, dy: INTEGER), NEW, ABSTRACT;
            (f: Model) Delete (v: Views.View), NEW, ABSTRACT;
            (f: Model) GetEmbeddingLimits (OUT minW, maxW, minH, maxH: INTEGER), EXTENSIBLE;
            (f: Model) Insert (v: Views.View; l, t, r, b: INTEGER), NEW, ABSTRACT;
            (f: Model) Move (v: Views.View; dx, dy: INTEGER), NEW, ABSTRACT;
            (f: Model) NewReader (old: Reader): Reader, NEW, ABSTRACT;
            (f: Model) NewWriter (old: Writer): Writer, NEW, ABSTRACT;
            (f: Model) NofViews (): INTEGER, NEW, ABSTRACT;
            (f: Model) PutAbove (v, pos: Views.View), NEW, ABSTRACT;
            (f: Model) Resize (v: Views.View; l, t, r, b: INTEGER), NEW, ABSTRACT;
            (f: Model) Top (): Views.View, NEW, ABSTRACT;
            (f: Model) ViewAt (x, y: INTEGER): Views.View, NEW, ABSTRACT
        END;

        Reader = POINTER TO ABSTRACT RECORD 
            view: Views.View;
            l, t, r, b: INTEGER;
            (rd: Reader) ReadView (OUT v: Views.View), NEW, ABSTRACT;
            (rd: Reader) Set (pos: Views.View), NEW, ABSTRACT
        END;

        Writer = POINTER TO ABSTRACT RECORD 
            (wr: Writer) Set (pos: Views.View), NEW, ABSTRACT;
            (wr: Writer) WriteView (v: Views.View; l, t, r, b: INTEGER), NEW, ABSTRACT
        END;

        UpdateMsg = RECORD (Models.UpdateMsg)
            l, t, r, b: INTEGER
        END;

    VAR
        dir-: Directory;
        stdDir-: Directory;

    PROCEDURE CloneOf (source: Model): Model;
    PROCEDURE Copy (source: Model): Model;
    PROCEDURE New (): Model;
    PROCEDURE SetDir (d: Directory);

END FormModels.

На форму с помощью Writer-а можно "записывать" новые контролы Views.View — кнопки, поля ввода, TreeControl и т.д...

Сравнивая FormModels.Reader и FormModels.Writer с ранее виденными rider-ами приходим к выводу, что синтаксически они с ними ни как не связаны — не существует обобщённого класса всех Reader-ов или Writer-ов на свете.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Если у бинарного файла, сокета и кусока памяти и есть что-то общее, то это не значит что и у всего остального тоже будет что-то общее, что можно выразить синтаксически.
Как сделать систему слабосвязанной я знаю не хуже тебя. Я давно понял что подразумевается под заумным мегапаттерном Carrier-Rider-Mapper (он же Model-View-Controller). Не нужно мне это объяснять.
Ты на прямой вопрос ответь: Почему File.Reader не был сделан расширением RandomReader'а?