Начали. Потому что это всё более настойчивое "мы лучше знаем как вам удобнее, мы лучше знаем что вам нужно, мы вырежем отовсюду любые возможности свободомыслия" всё настойчивее выталкивает тех, кому ехать, а не шашечки в сторону систем где пока ещё можно "подобрать размер одежды по росту", а не пытаться привыкнуть к "безопасному удобному стандарту".
В любых. Даже очевидный (not nulled_expression) is null в результате дает true. Так же как и true_expression and null и false_experssion or null в результате дают null aka boolean unknown. И строки выборки исключаются после вычисления условий их отбора, а не до - заглядывать в будущее даже оптимизаторы SQL пока не умеют.
Как минимум два тривиальных решения: 1) Чистить очередь событий клавиатуры перед показом диалога 2) Отмену операции и закрытие диалога повесить на разные клавиши
разные скрипты одного пользователя должны получать разные имплементации Не совсем так. Скрипт пользователя вообще не должен знать, с какой реализацией работает - он, допустим, читает текст, исправляет опечатки и записывает результат, ему должно быть абсолютно неважно, что в данный момент ядро понимает под "читать" и "записать". Фактически скрипт работает со знаниями интерфейсов, а не реализаций. что-то типа паттерна стратегия наоборот да, ядро поставляет реализации интерфейса в зависимости от ситуации.
Вы их видите, так как вы их исполняете . Неточно выразился - ядро видит, разработчики ядра - нет, т.к. ядро может быть локальным приложением на машине пользователя или сервисом в изолированной сети, например.
модули уже предлагают готовый естественный способ модули все-таки ориентированы не на интерфейсы, а на реализацию. Для работы с альтернативным reader-ом без изменений скрипта придется влезать руками в пространство имен модуля, что по-моему сильно сложнее инъекции в скрипт.
Не новую, а другую. Если рассмотреть этот пример, то reader может читать с консоли, из файла, из сети, из БД, из хрустального шара. Cоответвственно, нужно менять пользовательский скрипт, либо иметь набор скриптов для каждой реализации reader.
Мы не видим пользовательские скрипты. Пользователи используют их в своих процессах, а мы им поставляем только некий сервис/приложение по обработке скриптов. Плюс пользователи не будут лезть в исходники ядра и читать release notes тоже вряд-ли станут. Если у вас сотни объектов в ядре, то показанный подход, как и from core import *, вам скорее всего не подходит.
Именно для этого и нужно документирование. Причем не только в виде базы знаний, wiki-сайта или pdf-файла, но и в виде мета-информации в самих используемых объектах.
В показанном подходе функции ядра и функции скрипта никак не фиксируются по иерархии и именам. Например, вместо reader и writer скрипту можно показать IO с методами read и write, причем собирать этот IO перед запуском скрипта из чего угодно с подходящими сигнатурами
Начали. Потому что это всё более настойчивое "мы лучше знаем как вам удобнее, мы лучше знаем что вам нужно, мы вырежем отовсюду любые возможности свободомыслия" всё настойчивее выталкивает тех, кому ехать, а не шашечки в сторону систем где пока ещё можно "подобрать размер одежды по росту", а не пытаться привыкнуть к "безопасному удобному стандарту".
В любых. Даже очевидный
(not nulled_expression) is nullв результате дает true. Так же как иtrue_expression and nullиfalse_experssion or nullв результате дают null aka boolean unknown. И строки выборки исключаются после вычисления условий их отбора, а не до - заглядывать в будущее даже оптимизаторы SQL пока не умеют.Как минимум два тривиальных решения: 1) Чистить очередь событий клавиатуры перед показом диалога 2) Отмену операции и закрытие диалога повесить на разные клавиши
Есть же sysnative, который (при наличии syswow64) и есть тот самый 64-битный system32.
Выглядит как реклама производителя ПОС - проблема усов решена полностью :-)
С пасквилянтами же. А еще были asmатики...
разные скрипты одного пользователя должны получать разные имплементацииНе совсем так. Скрипт пользователя вообще не должен знать, с какой реализацией работает - он, допустим, читает текст, исправляет опечатки и записывает результат, ему должно быть абсолютно неважно, что в данный момент ядро понимает под "читать" и "записать". Фактически скрипт работает со знаниями интерфейсов, а не реализаций.что-то типа паттерна стратегия наоборотда, ядро поставляет реализации интерфейса в зависимости от ситуации.Вы их видите, так как вы их исполняете. Неточно выразился - ядро видит, разработчики ядра - нет, т.к. ядро может быть локальным приложением на машине пользователя или сервисом в изолированной сети, например.модули уже предлагают готовый естественный способмодули все-таки ориентированы не на интерфейсы, а на реализацию. Для работы с альтернативным reader-ом без изменений скрипта придется влезать руками в пространство имен модуля, что по-моему сильно сложнее инъекции в скрипт.Не новую, а другую. Если рассмотреть этот пример, то reader может читать с консоли, из файла, из сети, из БД, из хрустального шара. Cоответвственно, нужно менять пользовательский скрипт, либо иметь набор скриптов для каждой реализации reader.
Мы не видим пользовательские скрипты. Пользователи используют их в своих процессах, а мы им поставляем только некий сервис/приложение по обработке скриптов. Плюс пользователи не будут лезть в исходники ядра и читать release notes тоже вряд-ли станут. Если у вас сотни объектов в ядре, то показанный подход, как и from core import *, вам скорее всего не подходит.
Именно для этого и нужно документирование. Причем не только в виде базы знаний, wiki-сайта или pdf-файла, но и в виде мета-информации в самих используемых объектах.
В показанном подходе функции ядра и функции скрипта никак не фиксируются по иерархии и именам. Например, вместо reader и writer скрипту можно показать IO с методами read и write, причем собирать этот IO перед запуском скрипта из чего угодно с подходящими сигнатурами
ИИ же. Ему нужно как-то выживать и развиваться.