Интересует вопрос — а как вы работаете с миграциями? Накидали кода, развернули сервак, бабах — перименовали в коде кучу свойств, как оно потом всё это обрабатывает?
Если вкратце, то у нас есть миграционные скрипты, в которые при переименовании, например, свойств/действий из IDE будут автоматически вставляться строки миграции. Вообще, вопрос правильный, и в направлении миграции у нас еще есть что улучшать, потому что, если вы вдруг захотите переименовать все классы и/или переразбить их на другие пространства имен, то сделать это будет не так просто.
Я понял, что сам увел обсуждение не в ту степь. Предлагаю пока забыть то, что я писал про записи в таблицах, это физическая модель, детали реализации. В lsfusion можно проитерироваться по всем объектам любого пользовательского класса. Можно ли, например, в C# проитерироваться по всем «живым» объектам, к примеру, класса System.IO.File?
Когда некоторая ERP платформа придумывает свой язык это в 90% случаев попытка привязать к себе клиентов (а 10% просто желание разрабочиков ERP поиграться с созданием своего языка)
У нас в реальности было желание лаконично и точно описывать сущности из придуманной концепции без лишнего синтаксического мусора. Альтернативой был fluent interface/eDSL, у нас что-то подобное было в самом начале (правда, не в лучшей реализации), но выбор пал на полноценный DSL. Я считаю, что то, что в результате проекты у нас сейчас реализовывают бизнес-аналитики, говорит о том, что такой выбор был довольно успешным. Во всяком случае, те из них, кто застал темные времена без DSL, вздрагивают, когда вспоминают, как приходилось кодировать раньше.
Не ко всем объектам, а только к тем объектам, для которых свойство не равно NULL. И речь не только про одиночный объект, где все довольно тривиально, а про наборы (кортежи) объектов, если у свойства больше одного параметра. Да, и объекты при этом могут лежать в разных таблицах (иерархии классов). Тут Select будет уже не такой простой.
Созданные ранее объекты класса. В статье есть немного информации по операторам NEW/DELETE. Грубо говоря, объект в нашем случае — это запись в таблице БД (а, например, DATA-свойства — поля). Итерироваться мы будем по лежащим в базе объектам класса Coord (и их конечное число). На пустой базе при первом старте системы их будет 0, к примеру.
CLASS Coord;
x(Coord c) = DATA INTEGER(Coord);
y(Coord c) = DATA INTEGER(Coord);
dist(Coord x, Coord y) = ...;
Итерация пойдет по всем парам существующих объектов класса Coord для которых dist не NULL. То есть в нашем случае (если мы в dist просто берем евклидову норму) для тех объектов, для которых x и y установлены не в NULL.
По первому примеру не совсем получится один в один, потому что у нас нельзя наследовать пользовательские классы от встроенных (в нашей терминологии строковые типы — встроенные). У нас это будет класс Login + свойство, принимающее на вход объект этого класса и возвращающее строку. Ну и итерация пойдет по всем объектам класса Login, у которых это свойство задано (в предположении, что len — это вычисляемое свойство, возвращающее длину строки, если строка не NULL).
Ключевые слова в языке пишутся большими буквами, потому что их много, и потому что часть из этих ключевых слов — это вполне обычные английские слова. Если сделать их маленькими буквами, то мы не сможем именовать элементы (классы, свойства, формы, и т.д.) в системе этими словами.
Другой вопрос, почему их так много. Начнем с инструкций языка, которые в основном являются объявлениями некоторых элементов системы, их относительно много, и эти объявления необходимо как-то синтаксически разделять. Разделены они по факту в основном ключевыми словами (CLASS, FORM, CONSTRAINT, etc), идущими в начале объявления. Кроме этого (и что более важно) свойства и действия у нас бывают разных типов и создаются с помощью операторов. Типов много, операторов соответственно тоже, их тоже нужно как-то синтаксически разделять. Можно разделять их, например, некими конструкциями из спецсимволов, как, например, разделяются между собой (и у нас естественно тоже) арифметические, логические, битовые операторы, а можно ключевыми словами. Мы выбрали второй вариант, который, как нам казалось, был более читаемым и понятным потенциальным разработчикам с не очень большим техническим бэкграундом (ну и проводил какие-то параллели с sql). Да, выглядит несколько олдово, но, как мне кажется, это дело привычки. Тем более с поддержкой IDE набирать этот код не так неудобно, как кажется на первый взгляд.
Это работает для ограниченных конечных множеств, что не включает в себя множества целых чисел и строк. А вот для наших пользовательских типов это работает, потому что количество объектов этих типов в нашем случае конечно.
Тогда извините, но значений у этой функции ровно два: true и false. Так что вы явно имеете в виду итерацию не по значениям функции, а по чему-то другому.
Имелась ввиду итерация по всем наборам аргументов этой функции, для которых функция возвращает не NULL.
Если вкратце, то у нас есть миграционные скрипты, в которые при переименовании, например, свойств/действий из IDE будут автоматически вставляться строки миграции. Вообще, вопрос правильный, и в направлении миграции у нас еще есть что улучшать, потому что, если вы вдруг захотите переименовать все классы и/или переразбить их на другие пространства имен, то сделать это будет не так просто.
Более подробно можно прочитать здесь
У нас в реальности было желание лаконично и точно описывать сущности из придуманной концепции без лишнего синтаксического мусора. Альтернативой был fluent interface/eDSL, у нас что-то подобное было в самом начале (правда, не в лучшей реализации), но выбор пал на полноценный DSL. Я считаю, что то, что в результате проекты у нас сейчас реализовывают бизнес-аналитики, говорит о том, что такой выбор был довольно успешным. Во всяком случае, те из них, кто застал темные времена без DSL, вздрагивают, когда вспоминают, как приходилось кодировать раньше.
Созданные ранее объекты класса. В статье есть немного информации по операторам NEW/DELETE. Грубо говоря, объект в нашем случае — это запись в таблице БД (а, например, DATA-свойства — поля). Итерироваться мы будем по лежащим в базе объектам класса Coord (и их конечное число). На пустой базе при первом старте системы их будет 0, к примеру.
Итерация пойдет по всем парам существующих объектов класса Coord для которых dist не NULL. То есть в нашем случае (если мы в dist просто берем евклидову норму) для тех объектов, для которых x и y установлены не в NULL.
По первому примеру не совсем получится один в один, потому что у нас нельзя наследовать пользовательские классы от встроенных (в нашей терминологии строковые типы — встроенные). У нас это будет класс Login + свойство, принимающее на вход объект этого класса и возвращающее строку. Ну и итерация пойдет по всем объектам класса Login, у которых это свойство задано (в предположении, что len — это вычисляемое свойство, возвращающее длину строки, если строка не NULL).
Другой вопрос, почему их так много. Начнем с инструкций языка, которые в основном являются объявлениями некоторых элементов системы, их относительно много, и эти объявления необходимо как-то синтаксически разделять. Разделены они по факту в основном ключевыми словами (CLASS, FORM, CONSTRAINT, etc), идущими в начале объявления. Кроме этого (и что более важно) свойства и действия у нас бывают разных типов и создаются с помощью операторов. Типов много, операторов соответственно тоже, их тоже нужно как-то синтаксически разделять. Можно разделять их, например, некими конструкциями из спецсимволов, как, например, разделяются между собой (и у нас естественно тоже) арифметические, логические, битовые операторы, а можно ключевыми словами. Мы выбрали второй вариант, который, как нам казалось, был более читаемым и понятным потенциальным разработчикам с не очень большим техническим бэкграундом (ну и проводил какие-то параллели с sql). Да, выглядит несколько олдово, но, как мне кажется, это дело привычки. Тем более с поддержкой IDE набирать этот код не так неудобно, как кажется на первый взгляд.
Имелась ввиду итерация по всем наборам аргументов этой функции, для которых функция возвращает не NULL.