разные скрипты одного пользователя должны получать разные имплементации Не совсем так. Скрипт пользователя вообще не должен знать, с какой реализацией работает - он, допустим, читает текст, исправляет опечатки и записывает результат, ему должно быть абсолютно неважно, что в данный момент ядро понимает под "читать" и "записать". Фактически скрипт работает со знаниями интерфейсов, а не реализаций. что-то типа паттерна стратегия наоборот да, ядро поставляет реализации интерфейса в зависимости от ситуации.
Вы их видите, так как вы их исполняете . Неточно выразился - ядро видит, разработчики ядра - нет, т.к. ядро может быть локальным приложением на машине пользователя или сервисом в изолированной сети, например.
модули уже предлагают готовый естественный способ модули все-таки ориентированы не на интерфейсы, а на реализацию. Для работы с альтернативным reader-ом без изменений скрипта придется влезать руками в пространство имен модуля, что по-моему сильно сложнее инъекции в скрипт.
Не новую, а другую. Если рассмотреть этот пример, то reader может читать с консоли, из файла, из сети, из БД, из хрустального шара. Cоответвственно, нужно менять пользовательский скрипт, либо иметь набор скриптов для каждой реализации reader.
Мы не видим пользовательские скрипты. Пользователи используют их в своих процессах, а мы им поставляем только некий сервис/приложение по обработке скриптов. Плюс пользователи не будут лезть в исходники ядра и читать release notes тоже вряд-ли станут. Если у вас сотни объектов в ядре, то показанный подход, как и from core import *, вам скорее всего не подходит.
Именно для этого и нужно документирование. Причем не только в виде базы знаний, wiki-сайта или pdf-файла, но и в виде мета-информации в самих используемых объектах.
В показанном подходе функции ядра и функции скрипта никак не фиксируются по иерархии и именам. Например, вместо reader и writer скрипту можно показать IO с методами read и write, причем собирать этот IO перед запуском скрипта из чего угодно с подходящими сигнатурами
разные скрипты одного пользователя должны получать разные имплементацииНе совсем так. Скрипт пользователя вообще не должен знать, с какой реализацией работает - он, допустим, читает текст, исправляет опечатки и записывает результат, ему должно быть абсолютно неважно, что в данный момент ядро понимает под "читать" и "записать". Фактически скрипт работает со знаниями интерфейсов, а не реализаций.что-то типа паттерна стратегия наоборотда, ядро поставляет реализации интерфейса в зависимости от ситуации.Вы их видите, так как вы их исполняете. Неточно выразился - ядро видит, разработчики ядра - нет, т.к. ядро может быть локальным приложением на машине пользователя или сервисом в изолированной сети, например.модули уже предлагают готовый естественный способмодули все-таки ориентированы не на интерфейсы, а на реализацию. Для работы с альтернативным reader-ом без изменений скрипта придется влезать руками в пространство имен модуля, что по-моему сильно сложнее инъекции в скрипт.Не новую, а другую. Если рассмотреть этот пример, то reader может читать с консоли, из файла, из сети, из БД, из хрустального шара. Cоответвственно, нужно менять пользовательский скрипт, либо иметь набор скриптов для каждой реализации reader.
Мы не видим пользовательские скрипты. Пользователи используют их в своих процессах, а мы им поставляем только некий сервис/приложение по обработке скриптов. Плюс пользователи не будут лезть в исходники ядра и читать release notes тоже вряд-ли станут. Если у вас сотни объектов в ядре, то показанный подход, как и from core import *, вам скорее всего не подходит.
Именно для этого и нужно документирование. Причем не только в виде базы знаний, wiki-сайта или pdf-файла, но и в виде мета-информации в самих используемых объектах.
В показанном подходе функции ядра и функции скрипта никак не фиксируются по иерархии и именам. Например, вместо reader и writer скрипту можно показать IO с методами read и write, причем собирать этот IO перед запуском скрипта из чего угодно с подходящими сигнатурами
ИИ же. Ему нужно как-то выживать и развиваться.