OberonCore https://forum.oberoncore.ru/ |
|
Понятие модульности https://forum.oberoncore.ru/viewtopic.php?f=6&t=521 |
Страница 2 из 2 |
Автор: | Илья Ермаков [ Среда, 13 Июнь, 2007 10:58 ] |
Заголовок сообщения: | |
Сергей, я бы раньше не спорил, но у меня есть контрпримеры... Например, разрезая ядро ББ и переходя к микроядерности, я применил модульную архитектуру, с классическими для Оберонов приемами инсталлируемых хуков, а кое-где - и сообщений. И каждый из этих модулей будет легко заменяться как отдельный компонент, - для конкретной платформы или просто различной "заточенности" (как диспетчер памяти - агрессивная политика или мирная). Т.е. налицо все признаки модулей и модульной системы. Но в итоге конкретная версия ядра компонуется статически, т.к. технически никак иначе нельзя.. |
Автор: | PGR [ Среда, 13 Июнь, 2007 11:17 ] |
Заголовок сообщения: | |
Тогда чего Модулу назвали Модулой, оказывается модулей-то в ней и нет |
Автор: | Александр Ильин [ Среда, 13 Июнь, 2007 12:09 ] |
Заголовок сообщения: | |
PGR писал(а): Тогда чего Модулу назвали Модулой, оказывается модулей-то в ней и нет Тогда думали, что это модули.
Ведь и "новейшее время" в истории назвали так не потому, что новее не будет. |
Автор: | Trurl [ Среда, 13 Июнь, 2007 12:27 ] |
Заголовок сообщения: | |
А некоторые до сих пор считают си языком программирования. Надо в статье про оберон заменить "направления" -> "учения". |
Автор: | batyrmastyr [ Среда, 13 Июнь, 2007 14:38 ] |
Заголовок сообщения: | |
Trurl писал(а): А некоторые до сих пор считают си языком программирования.
Правильно считают, если не уточнять, что именно программировать (программы или баги) Лично мне один знакомый задвинул что JavaScript вообще не является языком программирования высокого уровня. |
Автор: | Сергей Губанов [ Среда, 13 Июнь, 2007 14:40 ] |
Заголовок сообщения: | |
Илья Ермаков писал(а): Сергей, я бы раньше не спорил, но у меня есть контрпримеры...
Ну, давайте поспорим. И так, давайте забудем, что модули предназначены для динамической загрузки и выгрузки. В чём же разница между: Код: MODULE A; IMPORT Log; BEGIN Log.String("Hello, World!") END A. и Код: static class A
{ static A () { System.Console.Write("Hello, World!"); } } Разницы-то нет!!! Аналогично и ваши микроядра - их можно было оформить (в .Net) как статические классы, ну и при чём тут модули? В общем, если забыть о динамической загрузке/выгрузке, то разница между модулями и статическими классами отсутствует, т. е. модули не нужны - вполне хватит статических классов. |
Автор: | Илья Ермаков [ Среда, 13 Июнь, 2007 15:08 ] |
Заголовок сообщения: | |
Классы тоже могут динамически загружаться-выгружаться, как в Яве. В Яве класс вообще эмулирует модуль. Проблема, во-первых, в том, что при такой эмуляции понятие класса дико семантически перегружено, а во-вторых, теряется много мелких нюансов, например - no paranoia rule. В результате модульные языки на порядок более выразительны архитектурно - вот оно, основное отличие, а не динамическая загрузка. |
Автор: | Илья Ермаков [ Среда, 13 Июнь, 2007 15:19 ] |
Заголовок сообщения: | |
Сергей Губанов писал(а): В общем, если забыть о динамической загрузке/выгрузке, то разница между модулями и статическими классами отсутствует, т. е. модули не нужны - вполне хватит статических классов.
А так оно и есть! "Вполне хватит". Вы пытаетесь охарактеризовать модули с точки зрения их свойств и механизмов. Это только одна сторона. Та же динамическая загрузка-выгрузка классов есть, как я уже сказал, в Java, есть, если память не изменяет, и в Objective C. Вопрос в различиях концепций, в том, что это разные абстракции, которые по-разному направляют мышление и проектирование. Какая разница между потоками-семафорами и активными объектами? В том, что вторые позволяют делать что-то особое, чего не позволяют первые? Да нет. И те, и другие позволяют писать приложения с параллельностью, так же, как и модули, и классы - в принципе - позволяют писать приложения с динамической загрузкой компонент. Они (модули по сравнению с классами, активные объекты по сравнению с потоками-семафорами) просто позволяют мыслить по-другому, по-другому абстрагировать задачу, по-другому конструировать систему. |
Автор: | Сергей Губанов [ Среда, 13 Июнь, 2007 15:36 ] |
Заголовок сообщения: | |
Илья Ермаков писал(а): Та же динамическая загрузка-выгрузка классов есть, как я уже сказал, в Java
Никакой динамической загрузки-выгрузки классов в природе не существует. Классам разрешено друг на друга ссылаться ("импортировать") или вообще быть объявленным один внутри другого. Два циклически ссылающихся друг на друга класса по отдельности загрузить и выгрузить невозможно. Они оба вместе образуют одну единую неделимую сущность - модуль. Так что в Java, как и где угодно (чудес-то не бывает), загрузка/выгрузка осуществляется не для классов, а для модулей даже если они там никак синтаксически не обозначены, а просто подразумеваются (и, в частном случае, могут состоять всего из одного класса). |
Автор: | Сергей Губанов [ Среда, 13 Июнь, 2007 15:41 ] |
Заголовок сообщения: | |
Илья Ермаков писал(а): Вы пытаетесь охарактеризовать модули с точки зрения их свойств и механизмов.
Нет, я их характеризую с точки зрения задачи которую они решают - динамическое расширение системы. Все остальные задачи можно решать и без модулей. |
Автор: | Сергей Губанов [ Среда, 13 Июнь, 2007 15:51 ] |
Заголовок сообщения: | |
Илья Ермаков писал(а): Проблема, во-первых, в том, что при такой эмуляции понятие класса дико семантически перегружено, а во-вторых, теряется много мелких нюансов, например - no paranoia rule. В результате модульные языки на порядок более выразительны архитектурно - вот оно, основное отличие, а не динамическая загрузка.
В .Net понятие static class означает примерно то что в Delphi означает unit (нельзя создать экземпляр статического класса, статический класс нельзя расширять, статический класс сам не может быть расширением другого, статический класс не может реализовывать интерфейсы). Разница лишь в том, что в Delphi секция инициализации юнита запускается при старте программы, а секция инициализации статического класса (статический конструктор) запускается при первом к нему обращении (т.е. может никогда не запуститься). Так что архитектурно (в статическом случае) static class от модуля-юнита не отличается. В статическом случае архитектурных различий нет. |
Автор: | PGR [ Четверг, 14 Июнь, 2007 16:12 ] |
Заголовок сообщения: | |
Сергей Губанов писал(а): Нет, я их характеризую с точки зрения задачи которую они решают - динамическое расширение системы. Все остальные задачи можно решать и без модулей.
А чем такие динамические модули отличаются от компонентов? |
Автор: | Сергей Губанов [ Четверг, 14 Июнь, 2007 16:18 ] |
Заголовок сообщения: | |
PGR писал(а): А чем такие динамические модули отличаются от компонентов?
Компонент, как правило, состоит из нескольких модулей. В Блэкбоксе компонентами являются подсистемы. |
Автор: | PGR [ Четверг, 14 Июнь, 2007 16:31 ] |
Заголовок сообщения: | |
Сергей Губанов писал(а): PGR писал(а): А чем такие динамические модули отличаются от компонентов? Компонент, как правило, состоит из нескольких модулей. Но может же состоять и из одного... Сергей Губанов писал(а): В Блэкбоксе компонентами являются подсистемы.
А что же тогда кластеры? |
Автор: | Илья Ермаков [ Четверг, 14 Июнь, 2007 16:39 ] |
Заголовок сообщения: | |
PGR писал(а): Сергей Губанов писал(а): В Блэкбоксе компонентами являются подсистемы. А что же тогда кластеры? Можно понимать под кластером конкретную совокупность взаимодействующих модулей, закоммутированных каким-либо образом. Границы кластеров не совпадают с границами компонентов/подсистем. Подсистема - это набор модулей с точки зрения назначения для пользователя, они могут вообще не взаимодействовать внутри подсистемы. С другой стороны, модули разных подсистем могут динамически закоммутироваться друг с другом и образовать кластер. |
Автор: | Борис Рюмшин [ Четверг, 14 Июнь, 2007 16:43 ] |
Заголовок сообщения: | |
ПЕРЕНЕСЕНО МОДЕРАТОРОМ: Trurl: Сергей Губанов писал(а): В общем, если забыть о динамической загрузке/выгрузке, то разница между модулями и статическими классами отсутствует, т. е. модули не нужны - вполне хватит статических классов.
Не так. Статические классы нужны - вполне хватит модулей. |
Автор: | PGR [ Четверг, 14 Июнь, 2007 16:51 ] |
Заголовок сообщения: | |
Цитата: Можно понимать под кластером конкретную совокупность взаимодействующих модулей, закоммутированных каким-либо образом. А когда-то Обероны стремились к простоте...
Границы кластеров не совпадают с границами компонентов/подсистем. Подсистема - это набор модулей с точки зрения назначения для пользователя, они могут вообще не взаимодействовать внутри подсистемы. С другой стороны, модули разных подсистем могут динамически закоммутироваться друг с другом и образовать кластер. |
Автор: | Илья Ермаков [ Четверг, 14 Июнь, 2007 22:32 ] |
Заголовок сообщения: | |
Но модули умели "браться за руки" так или иначе с самого начала Отсюда и появление термина "кластер". |
Автор: | PGR [ Пятница, 15 Июнь, 2007 00:10 ] |
Заголовок сообщения: | |
Илья Ермаков писал(а): Но модули умели "браться за руки" так или иначе с самого начала Отсюда и появление термина "кластер".
А что можно почитать о кластерах, когда появился этот термин по отношению к множеству взаимодействующих модулей? Непонятно, зачем вводить так много понятий: подсистема, компонент, кластер, ... |
Автор: | Илья Ермаков [ Пятница, 15 Июнь, 2007 01:03 ] |
Заголовок сообщения: | |
Да ничего нельзя почитать... Все это "живая" терминология, которая только формируется. Компонент - это компонент, общий термин в современном ИТ. Подсистема - это конкретный способ упорядочения модулей в ББ. Упорядочения для распространения и установки... Однако это всего лишь способ сгруппировать модули, никак не определеяющий их взаимодействие... Термин "кластер" пробуем применить к группам модулей, образовавшим связь с друг с другом посредством какого-то механизма (статический импорт, динамические разъемамы, шина сообщений...). В конечном счете большим кластером, конечно, является все запущенное приложение, т.к. связи его пронизывают насквозь, но можно четко выделить небольшие сильносвязные кластеры (самая сильная связь - двусторонняя, когда в одну сторону - по импорту, а в обратную - по динамическим разъемам). Например, Windows, HostWindows, Ports, HostPorts, HostMenus и еще некоторые другие образуют четкий кластер. При этом относятся к разным подсистемам. Kernel, Files, HostFiles, StdLoader - тоже кластер... Смысл введения термина "кластерно-модульное" - подчеркнуть ориентированность модульных языков на динамическую коммутацию модулей, а не просто на разделение системы на куски и их хранение в пакетах-"модулях" (которые модулями не являются). |
Страница 2 из 2 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |