Есть старенькая проблема, о которой я говорил в wrc еще 2012 году, ее номер 774493.
Это потенциальная уязвимость, которая чревата нарушением структуры данных на прикладном уровне, связанная с изменением структуры данных класса (добавлением новых полей) и неперекомпиляции программ с запросами на обновление данных. В то время мы сошлись на том, что исправлять ее слишком сложно, это затронет много чего, и решать это правильно на организационном уровне, а на на уровне СУБД. Тем не менее, о проблеме я не забыл, и до сих пор мне кажется, что иметь такую поганенькую проблему для такой прекрасной СУБД нехорошо, поэтому попробую предложить ее решить через форум. Тем более, я почему-то уверен, что сложность ее решения преувеличена, а опасность все-таки довольно высокая.

Суть проблемы попробую изобразить на примере. Создадим простенький класс из двух полей:



И две одинаковые программы test.mac и test2.mac с кодом из одной строчки


Скомпилируем эти программы и посмотрим их исходный код, он довольно прост:



Добавим в наш класс одно поле A2 (имя важно!), класс после этого будет выглядеть так:



И перекомпилируем только одну из них, ее int-код изменится:



Что же изменилось у нас в int-программах? В аргументах для программы ##class(Test.A).%SQLInsert()
Раньше они собирались в переменную так:

А после добавления так:



Т.е. после добавления поля изменился порядок принимаемых данных в %SQLInsert, и неперекомпилированная программа вставит данные не в то поле. Более точно - аргументы сортируются по их имени (почему и было важно было название добавляемого свойства). Поэтому, поле A2 заняло место поля B1, а B1 сместилось дальше. Подобная же штука происходит и при компиляции запросов на одновление. Т.е. если вы на своей базе добавили незначительное, как вам кажется, поле и не перекомпилировали все классы и программы, которые изменяют строки таблицы, порожденной модифицированным классом , вы рискуете получить повреждение данных. Причем это не явная модификация структуры хранения (при этом разработчик должен отдавать себе отчет), а автоматическая.
Да, неправильно запросы на обновление делать где-то кроме основного класса, да, существует система связанной перекомпиляции, но тем не менее, ошибки возможны, так как не при любом изменении класса хочется перекомпилировать весь продуктовый сервер, а зависимости перекомпиляции не учитывают, например, те же программы.

Блок А.Н.,

мне кажется, добавление переменных по их имени решило бы проблему.
например, так:

DAiMor,

Мм, $ET?

DAiMor,

Ну ладно, $ET это не совсем то, но смысл такой же.
Мне кажется, в Каше многим не хватает возможности передачи кода как аргумента, сохранения кода в переменную и так далее.
При том, что есть возможность передачи кода как строки. Но, видимо, это не очень удобно. Например, потому, что синтаксис кода в строке не подсвечивается, очень неудобно делать многострочный код. Может быть, сделать команду превращения кода в строку, а еще лучше - в специльную структуру, которую потом можно выполнить или передать как аргумент.
Блин, кажется, я анонимные функции изобрел :-) А почему нет? Ведь для этого почти все есть. Тот же $XECUTE работает можно сказать, как исполнитель анонимных функций. Даже под это специальный формат строки есть.

DAiMor,

$ET - это переменная, которая содержит код, который выполняется при определенных условиях. Разве не этого же по сути вы хотите от DEFER?

Мне кажется, оператор типа
for(key in global) немного улучшил читаемость и сократил код при работе с многомерными переменными.