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

K>Здравствуйте, Андрей Хропов, Вы писали:

АХ>>Здравствуйте, Kolhoz, Вы писали:


K>>> Опять 5*5... Эта компонентность не более мощная. Она более частная. Она реализуется тривиально поверх примитивов unix way, а вот unix way поверх объектной компонентной модели — нет. Не сравнивайте даже общее решение с частным!
АХ>> Да все в точности наоборот!
АХ>> Передайте от одного компонента другому имя файла и будет вам полнейший Unix way.

K> Какого файла? А если я туда netcat вставил? Или ssh?
И? В чем проблема?
Передайте имя файла netcatу, а он дальше передаст.

то что вы пишете в Unix как
"ls | more"
можно записать как (условно)
"File result = more.Process( ls.Process(input) )".
more и ls некие компоненты.

Чуть больше слов, но суть та же.

АХ>> Весь этот Unix way сводится просто к сериализации/десериализации в/из потоков (они же файлы).

K> Нет.

K> Дао Unix way:
K>- на каждую функциональную единицу — отдельный компонент
Правильно — в любой компонентной системе так.

K>- к компоненту предъявляются требования:
K> * возможность как программного так и интерактивного задействования всех его функций.
Правильно. Так как вы там интерактивность в Unix way обеспечиваете?

K> * корректное сообщение о любых исключительных ситуациях
Сообщение мало. Надо еще данные не убить по возможности.
Без поддержки исключений обработка ошибок — это геморрой жуткий.
Я уж не говорю про RAII. А это предполагает ОО.

K> * наличие максимально простого для программной обработки протокола передачи как потребляемых, так и производимых компонентом данных.
K>- в системе из нескольких компонент между любыми двумя компонентами должна быть возможность встроить третий
Эээ. Вот тут мне видится фундаментальный изъян.
Дело в том что для того чтобы вставить на вход одного компонента выхлоп из другого нужно чтобы у них были совместимы интерфейсы, т.е. передаваемая информация была в одном формате,
в unix way используется наименьший общий знаменатель — простой текст.
Часто программы работают все же не с простым текстом, а со структурированными данными
(простейшие утилиты вроде grep не берем в расчет), поэтому имеем оверхед на сериализацию/десериализацию.
А любой компонент в середину все равно нельзя, поскольку обработка разной информации требует разных компонентов (пример с закодированными символами в HTML уже приводился, так же можно сказать что с ASCII и Unicode надо работать по-разному и т.п.).

Вот LaTeX — это Unix way?
в цепочке "latex -> dvips -> ps2pdf" ты можешь вставить (точнее, смысл есть?) между dvips и ps2pdf grep?

K> Всё. Текстовые потоки, awk-и с netcat-ами — это частности и следствия означенного дао.
Имеют свои плюсы, но не универсальны.

АХ>> Это конечно было замечательно в 70-е (и даже в 80-е) годы, но сейчас уже придумали кой-чего получше.

K> Что же? Объектно-ориентированную религию не предлагать, тошно-с.
Глупости говорите. ОО давно уже само-собой. Теперь уже дальше идем в сторону скрещения ОО с функциональщиной . Даже в скриптовых языках, без которых Unix way никуда .