OberonCore

Что есть хуки в Ящике и какую роль они выполняют?

Например, генератор диалоговой формы FormGen.Create вызывает процедуру Views.Open(v, loc, name, NIL) для открытия отображения в отдельнном окне, а та, в свою очередь, обращается к методу viewHook.Open. Переменная viewHook имеет абстрактный тип ViewHook, с абстрактными же методами, которые реализуются в StdDialog, там же и создаётся экземпляр viewHook.

Ещё, на форуме "Мысли об Обероне" есть такое сообщение двухлетней давности:


(Собс-но, в этом и причина, почему хуки не показываются в интерфейсе, в обычном режиме.)

Интересует именно архитектурное назначение хуков, почему именно хуки, и почему именно так?

Хук - это объектно-ориентированный разъём между модулями. Модуль реализации подключает этот разъём к интерфейсному модулю. Подробнее объяснено в http://oberoncore.ru/download/articles/DesignIdeas.pdf . Проще говоря, это вариация из той же оперы, что и Directories - для разделения интерфейса и конкретных реализаций.

Илья, спасибо за ответ!
Насколько я понимаю, директория - это "фабрика", в терминах OO Patterns. Хук как разьём... Да, век живи — век учись Перечитываю DesignIdeas под другим углом зрения

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

Ой, не зря BlackBox носит такое название. Идеологическое название, а эта идеология прослеживается ну просто повсюду.

Иван, Вы нашли красивое толкование Hook! Спасибо за идею!
У Вас, видимо, мозги не запорошены WinApi, потому что я до сего момента считал название Hook (трактуя его как "перехватчик") неудачным

А ещё есть перевод "ловушка", в документации к модулю DevBrowser. Заглянул в словарь, у слова Hook много толкований, есть и "гак, захватка, зацепка", близко к перехвату. Но большинство значений из словаря (Lingvo) описывают вот это вот "одностороннее взаимодействие", ну или как ещё назвать зацепление чего-то кем-то с проявлением активности\пассивности.
Почитал про перехваты в WinApi, там же вроде бы замещение системных функций своими, то есть "перехват" обращения, перехват вызова. Только почему-то речь идёт о "перехвате функции", "обходе" (detour) и "трамплине" (trampoline). По мне, так это неаккуратное обращение с языком, с понятийным аппаратом и произвольное подтягивание понятий.
Другое дело, hooks in the BlackBox. Слово не расходится с делом, образы соответствуют описанию - компоненты, ящики, а ящики можно крюками цеплять друг к другу

Слов то много можно придумать...
А смысл все равно один - ООП имеет много понтов и придумало много
новых слов для называния старых известных вещей.
Но реально все равно ООП оказывается не способно обеспечить все
нужные на практике разновидности расширяемости. И тем более не
способно полностью поддержать все виды _модифицирования_ проекта
(поскольку _урезание_ все равно не поддерживается).
Все равно приходится делать вручную.
Так что ООП был и остается частным, не основным механизмом языка и
использовать его надо лишь в редких оправданных случаях.
И по возможности обходиться простыми модулями.
И соответственно, рабочий язык у меня например остается Модула-2,
изредка поглядывая на Оберон-1))
А уж все что _после_ Оберон-1 считаю вообще лишь академическими
экспериментами)) Это конечно лишь личное мнение, а не повод для флейма))

Чисто для расширения моего кругозора попросил бы Вас перечислить все разновидности расширяемости и виды модифицирования проекта. Такая классификация очень полезна.

ООП в Обероне (КП) как раз в пределах нормы... Я за то, чтобы использовать его не как "целую пилюлю", а как отдельные игридиенты в разных случаях. Когда нужно - расширение типа. Когда нужно - виртуализацию. Когда нужно - для описания абстрактных интерфейсов и создания разъёмов.

а нету одновременно и полной и общепринятой)) сейчас общепринято всюду совать ООП. которое позволяет лишь расширять некоторые заранее предназначенные для этого части программы. но для этого надо заранее запланировать в архитектуре все возможные направления модификации. и потом говорят придется только добавлять код. в реальности оказывается)) что иногда кое-что нельзя было предвидеть при проектировании и как следствие возникает проблема "хрупких базовых классов" - часть системы уже нельзя изменить потому что развалится хитро зависящая от ее особенностей часть. и зависимостей если повсюду совать ООП будет мноого))
А для классификации... ну попробуйте например для начала представить себе морфологический ящик комбинаций расширений-сохранений-УРЕЗАНИЙ пары модульсервис-модульклиент... и пометьте галочками какие из 9 вариантов поддержит ООП... и почему нужны хуки...

Да, без общего тезауруса можно "далеко уйти", я так считаю
С удивлением обнаружил, что под рукой, на самом деле, нет чёткого понятийного аппарата, который бы охватил и программную систему в целом, и модульность, и расширяемость, и сопровождение-модификацию. В интернете встретил такую формулировку:

Так что в природе кое-что есть, это просто я не в курсе

То, что есть, - в основном громоздкие методологии, так называемые "процессы", которые представляют собой организационные костыли для менеджирафф Тот же UML в конечном счёте выродился именно в такие костыли. Способ сохранить иллюзию, что сложность удерживается под контролем...(а на самом деле стремительно растёт и вываливается на следующего потребителя в цепочке, прямо как НДС... Надо вводить Налог на Добавленную Сложность)

Батенька, бухгалтерия на вас плохо влияет. Пора завязывать.

Вот разберусь... И завяжу