Как ваша платформа понимает, что делать когда вы пишете «quantityReserved(st,sk)»?
Давайте попробуем еще раз на пальцах (насколько смогу). quantityReserved в данном случае в терминологии lsfusion называется «свойство». Свойство — это, грубо говоря, некоторая вычисляемая функция (как в математике), То есть какая-то штука, которая принимает на вход параметры, и возвращает значение, являющееся результатом некоторого вычисления. Только кроме логических, арифметических и т.п. операторов в lsfusion для вычисления есть еще операторы композиции, группировки, рекурсии и т.д.
Теперь вы хотите повесить ограничение на какое-то сложное вычисляемое значение. В lsfusion для этого значения вам нужно создать свойство (оно может быть создано и прямо в инструкции CONSTRAINT). То есть его нужно создать в любом случае, если хотите его вычислить, это и есть описание логики. Создаваться оно будет, как описывалось выше, в коде с помощью существующих операторов. quantityReserved в данном примере — это просто ранее объявленное свойство с соотвествующей логикой, вычисляющей то, что она должна по примеру вычислять.
В том, что у 1C есть большое коммьюнити и Q&A ресурсы, никто не сомневается. (1310 вопросов — это, правда, как-то мелковато для того количества программистов и того времени, которое существует платформа). На ru.stackoverflow, например, есть еще 3-4 сотни вопросов. Вот только это ни разу не документация. По Q&A вряд ли получится что-то с нуля изучить.
Мы вам уже на это не один раз отвечали, что логика в CONSTRAINT может быть абсолютно любая, то есть вы можете повесить ограничение на любое вычисляемое свойство. Мне, например, непонятно, что именно вам непонятно в слове «любая»? Вот все, что сможете на нашем языке (полном по Тьюрингу) изобразить, на все и можно будет повесить одной строкой кода.
простые встроенные в платформу проверки из lsfusion, которые быстро превращаются в цепочку вызовов неизвестных внешних процедур
Вы столько уже написали в обсуждениях нашей платформы, но до сих пор не поняли, что никаких «процедур» в обсуждаемом контексте у нас нет.
Причём не приводя в пример достоинства своей системы
В блоге, в котором размещена эта статья, есть набор статей, где рассказывается о достоинствах.
Но заявлять это можно будет только тогда, когда она займёт хотя бы какую-то долю рынка.
Это называется «сперва добейся». Так себе позиция. Да, эта статья в основном о «технических плюшках» и написана она не для конечных пользователей (если речь о пользователях решений).
Вы сами привели простой(!) пример, с которым ваша система не справилась
Это был не пример того, как система не справилась, а пример того, как система подскажет программисту, что он что-то забыл при изменении базовой функциональности.
Непонятно, зачем вы пробуете притянуть за уши терминологию, которая не имеет никакого отношения к обсуждаемой теме. Речь конкретно о булевых функциях, это вполне простой и понятный термин.
Хэш-функция — это любая функция, (неуникально) отображающая пространство бОльшего размера на пространство меньшего размер
Я не буду комментировать это определение, только замечу, что булева функция f(b) = b ему не соотвествует.
Вы в математику вообще умеете? Там очень многое основывается на предельных случаях (утрируя, «докажем теорему для N участников… рассмотрим случай, когда N=1...») и индукции.
Ну да, самое удачное место спросить собеседника о том, знает ли он, что такое индукция — это в комментариях к статье о доказательстве математической гипотезы.
Гипотеза, о которой будут говорить — про хэш-функции
Хэш-функция с двумя значениями? Полезно. Если уж хочется зачем-то дать синоним булевой функции, то это называется «предикат».
Пример одного из таких алгоритмов
Этот «алгоритм» называется AND, конъюнкция
Пример другого алгоритма того же класса
А этот XOR.
То есть, по сути, в том абзаце дается сначала примерное определение булевых функций «на пальцах». Затем приводят два примера: and и xor. А затем следует действительно какое-то капитанское утверждение.
Это все схожести на лексическом уровне. То есть Fortran (вернее не Fortran, а скорее Algol или Oberon) напоминает большими буквами в ключевых словах, ABAP большим количеством ключевых слов (больше не знаю, чем может напоминать, но я видел мало кода на ABAP). Так можно и c SQL сравнить, хотя с SQL схожесть можно найти уже не только на лексическом уровне. Но если посмотреть чуть выше, хотя бы на синтаксический уровень, то нет, не похож lsfusion ни на Fortran, ни на ABAP, совсем.
Хм, да, в мобильной версии эта страница сейчас выглядит не слишком понятно. В полной версии (desktop version) она больше похожа на стартовую страницу описания языка, с содержанием в виде дерева слева.
Еще приметил статейку с примерами в блоге компании
Да, статьи с названиями «Не очередной язык программирования. Часть N...» предполагались, как своеобразный tutorial, в них есть описание языка и примеры.
Ну так вроде же в том же обсуждении уже выяснили, что нет никаких объектов суррогатных классов, не нужны они низачем. Можете привести пример, когда вам зачем-то нужен такой объект?
Ок, надо точнее выразить свою мысль. Если мы вернемся к самому первому предложению по синтаксису. И будем говорить о какой-то другой сущности, которая не является классом в lsfusion: какое-то новое понятие агрегата (кортежа) нескольких классов, то ок, все возможно, мы вроде бы уже остановились на этом. Это будет какой-то новый синтаксис, новое понятие поверх наших классов. Это нормальное предложение, но нужно взвешивать его плюсы и минусы.
Но если мы все еще обсуждаем вариант, в котором реально создается новый класс, класс в терминологии lsfusion. То в этом случае нет смысла в классе без объектов, если класс не абстрактный.
Можете показать пример полиморфизма, в котором вам мешает явное введение промежуточной сущности?
Можем ради интереса обсудить классический пример про астероиды. Я покажу на примере действий, со свойствами будет идентично. Вот как это будет выглядеть на lsfusion:
Объявляем абстрактный класс с абстрактным действием:
CLASS ABSTRACT Collidable;
collide ABSTRACT (Collidable, Collidable);
Используем где-нибудь это действие:
randomProcess(Collidable a, Collidable b) {
...
collide(a, b);
...
}
Затем в каких-нибудь других модулях (скорее всего различных) объявляем классы:
CLASS Spaceship : Collidable;
CLASS Asteroid : Collidable;
И добавляем реализации для различных вариантов:
collide(Asteroid a, Asteroid b) + { ... }
collide(Asteroid a, Spaceship b) + { ... }
collide(Spaceship a, Asteroid b) + { ... }
collide(Spaceship a, Spaceship b) + { ... }
Теперь при использовании действия collide где-то в базовом модуле, будет вызываться нужная реализация, в зависимости от реальных рантайм классов объектов.
Я может быть просто не понимаю, как это будет выглядеть при добавлении «третьих» классов. Можете показать?
Мы уже это обсуждали выше. Во-первых, появляются объекты этих суррогатных классов, их временем жизни надо как-то управлять. Это не самостоятельные сущности, они зависимые. Затем, вот у нас есть иерархия классов с базовым классом Товар и иерархия классов с базовым классом Склад, нам теперь все пары классов из этих двух иерархий создавать? А если тройки? А четверки?
Другая проблема, которая сразу приходит на ум — это невозможность multiple dispatch без дополнительных усилий. То есть предложение делать сущности для пар, троек и т.д. объектов — это попытка вписать все в модель с инкапсуляцией и single-dispatch, то есть классическую ООП модель, которая существует во многих распространенных языках программирования (да, это привычно, я понимаю). В этой модели, если нам нужен полиморфизм по нескольким параметрам, то придется либо создавать на каждую пару по классу: SpaceshipSpaceship, SpaceshipAsteroid, AsteroidAsteroid (и делать вид, что это хорошее решение), либо переизобретать паттерн Visitor. А у нас нет инкапсуляции, зато мы получили multiple dispatch без особых усилий. Ну вот такой подход у нас.
В таблице с ключами (Person, Person). А может храниться в таблице (Object, Object) или (Person, Object). В конкретном примере в этом нет смысла, но для классов, которые являются частью какой-нибудь иерахии классов, смысл есть.
Ну получается вы из-за нескольких случаев, когда надо сделать зависимость свойства от двух классов, сделали неудобный синтаксис, которым надо пользоваться во всех остальных.
Во-первых, неудобный — это ваша субъективная оценка. Он, кстати, довольно логичный и естественный, если знать язык. Но вы судите без знания языка, поэтому вам кажется такой синтаксис чужеродным. Во-вторых, нет, не из-за нескольких случаев, у нас очень высокая доля таких свойств в проектах.
Просто хочу сказать, что вариант, о котором я говорю, не повлияет на преимущества, которые вы назвали (мультиметоды, расширения классов и т.д.)
Если речь о варианте с синтаксической конструкцией, то не повлияет. Если речь о cоздании «третьих классов» и переходе на single dispatch, то, конечно, повлияет. Но это, похоже, долгий разговор.
Теперь вы хотите повесить ограничение на какое-то сложное вычисляемое значение. В lsfusion для этого значения вам нужно создать свойство (оно может быть создано и прямо в инструкции CONSTRAINT). То есть его нужно создать в любом случае, если хотите его вычислить, это и есть описание логики. Создаваться оно будет, как описывалось выше, в коде с помощью существующих операторов. quantityReserved в данном примере — это просто ранее объявленное свойство с соотвествующей логикой, вычисляющей то, что она должна по примеру вычислять.
Это не детский сад. Термин «процедура» подразумевает императивное выполнение, которого там нет. И это просто маркер недопонимания.
Вы столько уже написали в обсуждениях нашей платформы, но до сих пор не поняли, что никаких «процедур» в обсуждаемом контексте у нас нет.
Это называется «сперва добейся». Так себе позиция. Да, эта статья в основном о «технических плюшках» и написана она не для конечных пользователей (если речь о пользователях решений).
Это был не пример того, как система не справилась, а пример того, как система подскажет программисту, что он что-то забыл при изменении базовой функциональности.
Я не буду комментировать это определение, только замечу, что булева функция f(b) = b ему не соотвествует.
Ну да, самое удачное место спросить собеседника о том, знает ли он, что такое индукция — это в комментариях к статье о доказательстве математической гипотезы.
Этот «алгоритм» называется AND, конъюнкция
А этот XOR.
То есть, по сути, в том абзаце дается сначала примерное определение булевых функций «на пальцах». Затем приводят два примера: and и xor. А затем следует действительно какое-то капитанское утверждение.
Да, статьи с названиями «Не очередной язык программирования. Часть N...» предполагались, как своеобразный tutorial, в них есть описание языка и примеры.
Но если мы все еще обсуждаем вариант, в котором реально создается новый класс, класс в терминологии lsfusion. То в этом случае нет смысла в классе без объектов, если класс не абстрактный.
Можем ради интереса обсудить классический пример про астероиды. Я покажу на примере действий, со свойствами будет идентично. Вот как это будет выглядеть на lsfusion:
Объявляем абстрактный класс с абстрактным действием:
Используем где-нибудь это действие:
Затем в каких-нибудь других модулях (скорее всего различных) объявляем классы:
И добавляем реализации для различных вариантов:
Теперь при использовании действия collide где-то в базовом модуле, будет вызываться нужная реализация, в зависимости от реальных рантайм классов объектов.
Я может быть просто не понимаю, как это будет выглядеть при добавлении «третьих» классов. Можете показать?
Другая проблема, которая сразу приходит на ум — это невозможность multiple dispatch без дополнительных усилий. То есть предложение делать сущности для пар, троек и т.д. объектов — это попытка вписать все в модель с инкапсуляцией и single-dispatch, то есть классическую ООП модель, которая существует во многих распространенных языках программирования (да, это привычно, я понимаю). В этой модели, если нам нужен полиморфизм по нескольким параметрам, то придется либо создавать на каждую пару по классу: SpaceshipSpaceship, SpaceshipAsteroid, AsteroidAsteroid (и делать вид, что это хорошее решение), либо переизобретать паттерн Visitor. А у нас нет инкапсуляции, зато мы получили multiple dispatch без особых усилий. Ну вот такой подход у нас.
Если речь о варианте с синтаксической конструкцией, то не повлияет. Если речь о cоздании «третьих классов» и переходе на single dispatch, то, конечно, повлияет. Но это, похоже, долгий разговор.