|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Oleg Goodyckov 2:5020/400 27 Jun 2003 15:17:54
To : Dmitry Astapov
Subject : Re: еще по поводу модератора
--------------------------------------------------------------------------------
On Fri, Jun 27, 2003 at 11:53:46AM +0400, Dmitry Astapov wrote:
> OG> Так и не надо нарушать. Разве функциональность любого пакета
> OG> развивается не тем же путём, что и функциональность класса объектов?
> Советую почитать, например, статью "A critique of object-orientation - a
> technical diatribe"
> (http://www.programmersheaven.com/search/download.asp?FileID=15651), в
> особенности - раздел о вреде одной иерархии класифицирования и
> невозможности завести несколько.
А можно в двух словах узнать смысл невозможности? Бо я скорее всего не
буду читать статью.
> OG> По-моему, тем же - от простого к сложному.
> А если более формально? Что есть "простое", что есть "сложное"? Я точно так
> же могу сказать, что все развивается от синего к зеленому ...
В математическом смысле, по Колмогорову: сложность объекта есть длина
минимального его описания. Объём программ вполне может служить показателем
сложности (исключая патологические случаи натыкивания лишнего кода). Объём
кода растёт от версии к версии. Следовательно, сложность пакета растёт.
> OG> Фактически, между ними нет разницы.
> Фактически, между ними есть разница.
Какая?
> OG> Чистая условность (мы ведь вполне можем написать весь пакет как одно
> OG> большое приложение - набор классов и объектов, опуская из рассмотрения
> OG> качество результата).
> Вот именно. Ты уверен, что для любого пакета ты сможешь построить объектную
> модель, реализовать ее, и не потерять в функциональности?
Если слово "любого" - в математическом смысле, то нет, не уверен. Hо на
практике, мы можем тривиально взять и простым объединением кодов всех
исполняемых файлов в один и дописыванием несложного обработчика запросов
(который будет потом вызвать любую из частей огромного командного файла)
достичь указанной цели. Собственно, если взять все системные программы,
расположить их в одном непрерывном экстенте RAM-диска, то запуск любой из
тех утилит и будет реализацией того, о чём я говорил. А ОС будет вполне
себе объектом класса "ОС Линукс", например.
Согласен, что это пример применения грубой и невежливой силы в тонком деле
ООП ;))) Hо как ни верти, а результат будет именно таким, как если бы мы
взяли и сначала создали объектную модель, а потом написали бы по ней весь
код - получится библиотека программ и набор разделяемых ими данных. А уж
как организовать вызовы тех программ - дело совершенно десятое.
> OG> В конечном итоге, нам, в принципе, никто не мешает применив означенный
> OG> механизм ООП к пакетам, расширить и дополнить его особенностями,
> OG> присущими именно пакетам. Hикто не говорит, что оба механизма должны
> OG> быть непременно и полностью тождественны. Hо механизм познего
> OG> связывания в применении к пакетам мне нравится.
> Эээээ... Тогда давай сюда свое определение пакета. Потому как слова
> "позднее связывание" и "пакет libxyz-dev" (или "kernel-doc") у меня как-то
> в голове рядом не ложаться ...
Пакет - в обычном смысле этого слова. А вот позднее связывание... Тут надо
прояснить, связывание чего с чем. В ООП связываются методы с вызовами. Здесь
то же, но "вызовом" здесь будет операция копирования файла (метода в
терминологии ООП) в определённое место на диске (или трансляции,
редактирования связей и т.п.). Так что аналогом таблицы виртуальных
методов ООП здесь будет служить файл, описывающий все связи между файлами
внутри всех версий пакета. Конкретно - пути формированию текущей версии
пакета из имеющихся файлов. Мне сильно кажется, что в роли такого файла
может выступать всем хорошо известный Makefile. Поскольку, как тут метко
заметил Вагнер, язык написания этих файлов относится к разряду языков
логического программирования, а реализация древовидных (иерархических то
бишь) структур - первейшее призвание таких языков.
--- ifmail v.2.15dev5
* Origin: unknown (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
