> -- Пётр Кушнир писал(а):
> Нет, не между собой, а в одну сторону, хост реализует предоставленные интерфейсы. Подозреваю, что в новом ББ старая хост-часть JU будет вообще не нужна. И включать её в состав другой подсистемы значит вводить зависимость от старого хоста во всю подсистему.Что значит, "вводить зависимость во всю подсистему"? Да, хост реализует интерфейс JUmgr. Это интерфейсная зависимость. Но JUmgr не может функционировать без JUhost, это функциональная зависимость. Если функциональные модули положить в общую папку, разве это повлияет на интерфейсные и функциональные зависимости? Никак не повлияет. Поэтому говорить о наличии каких-то других,особенныхзависимостей в общей подсистеме нельзя, это рассуждения ни о чём.

> -- Пётр Кушнир писал(а):
> Это субъективные вещи.Я вижу только функциональные и интерфейсные зависимости. Расположение модулей по разным подсистемам на них никак не влияет. Если это субъективно, значит, я не вижу ещё каких-то зависимостей, вопрос - каких?


> -- Пётр Кушнир писал(а):
> В WinAOS вообще нет подсистем. И не страдают.emb и dir встраиваемые частиmgr программерскаяhost платформозависимаяstd утилитарнаяapp базоваяВ подсистеме Projector, например, 84 модуля. Их тоже можно поделить на подобные функциональные части (не менее десятка возможных подсистем, с лёту можно насчитать), но они лежат в одной папке и никакие зависимости не нарушаются.

> -- Пётр Кушнир писал(а):
> Конечно, если намеренно говорить "А можно ли использовать app отдельно?" всегда будет за что потыкать. Это зависимость, запрещать зависимости теперь чтоли?Можно использовать emb без mgr, можно не использовать ни emb, ни dir, ни mgr, и при этом останется возможность написать своё приложение для JU.Я думаю, стоит определить, с какими видами зависимостей мы имеем дело, объективно. Чтобы не допускать субъективной группировки модулей по какому угодно принципу.

> -- Пётр Кушнир писал(а):
> Я уже разбирал это определение в рассылке ББ в споре про O3, в определении никак не ограничивается состав компонентов, если у меня компонент в виде двух подсистем, никто этого не регулирует и не предопределяет законы по размещению модулей.Начнём с того, что это не жёсткое определение, а довольно размытое соглашение. Для нас же важно определить виды зависимостей, чтобы понимать - когда выгодно выделить отдельную подсистему, а когда это выделение увеличивает сложность. Да, и подсистема - это не компонент. Можно взять определение Куно Пфистера, которое опирается на понятие интерфейса компонента, связанного с его содержанием. А у подсистемы нет интерфейса, потому что это коллекция компонентов.

> -- Пётр Кушнир писал(а):
> Если их поставить рядом, то легко увидим - JUhost покрашена в красный, а  взаимосвязи остались без изменений. Суть не поменялась.

> -- Пётр Кушнир писал(а):
> Тогда понятно, что существуют вполне очевидные пользовательские службы, которые имеют разные цели.Речь идёт о функциональных блоках, это очевидно. "Пользовательская служба" (кстати, что это?) никоим образом не требует для себя отдельной подсистемы в обязательном порядке.

> -- Пётр Кушнир писал(а):
> Объединение JUapp и JUstd будет нарушать схемуНикаких новых зависимостей не появляется, объединение чисто механическое, файлы переложили в одну папку, а на функциональности компонентов это вообще никак не отразилось. Или тут речь о каком-то другом объединении, которое формализуется в исходных текстах?

> -- Пётр Кушнир писал(а):
> , в которой появляется JUsuperApp, которое использует только стандартные модули JU, дополняя сущности app новыми.Файлы всего лишь положили в одну папку, и это вызвало необходимость появления новой сущности? С чего вдруг?

> -- Пётр Кушнир писал(а):
> Это наследие кровавого монолитного прошлого, удобнее компилировать из одного списка, и, это не единая подсистема.Для новых пользователей это тест на сообразительность - попробуй найди список компиляции JUНе сообразил - значит, по интеллекту не подходишь, систему JU тебе не судьба юзать!