Первый пример кода на новом языке разработки Dynamics NAV - AL

[rmv]

Цитата:

Сообщение от Predatore

И чем же синтаксис Javascript кардинально отличается от шарпового синтаксиса?
Вы же не думаете, что нам вот прям новый язык выкатят, максимум синтаксического сахарку дадут в качестве той же замены BEGIN END на {} и дай Бог, перестанут заставлять ставить двоеточие перед знаком присвоения.
То что нам показали, это всё тот же C/AL, только без устаревшего 20 лет назад интерфейса объявления переменных.

Дело не в синтаксисе, а в языках. Один со строгой типизацией, другой нет.
В одном я использую замыкания и в функции высших порядков, в другом ООП.
Лично меня сдвиг бизнес-логики Нава в парадигму наследования ООП совершенно точно не порадует - на мой взгляд у бизнес-объектов общими могут быть только методы логирования и доступа к данным.
Так что текущие ограничения вполне закономерно определяют и возможности разработчиков обойти стандарты и сломать систему - вспомните к примеру жаркую дискуссию по поводу try..catch с возможностью продолжить выполнение кода после отката транзакции.
Хотя честно говоря иногда очень хочется написать что-то вроде
addEvent(table, 'modify', function(event) { dispatch(event) });
или
addEvent(form, 'keyUp', function(event) { dispatch(event) });

[Predatore]

Цитата:

Сообщение от rmv

Лично меня сдвиг бизнес-логики Нава в парадигму наследования ООП совершенно точно не порадует - на мой взгляд у бизнес-объектов общими могут быть только методы логирования и доступа к данным.
Так что текущие ограничения вполне закономерно определяют и возможности разработчиков обойти стандарты и сломать систему - вспомните к примеру жаркую дискуссию по поводу try..catch с возможностью продолжить выполнение кода после отката транзакции.
Хотя честно говоря иногда очень хочется написать что-то вроде
addEvent(table, 'modify', function(event) { dispatch(event) });
или
addEvent(form, 'keyUp', function(event) { dispatch(event) });

Ещё у них могут быть общими представления. Вам серьёзно не кажется, что одни и те же печатки для учтёнки и не учтёнки, это не совсем правильно? Особенно учтивая что их нужно поддерживать параллельно!
Логика тоже может быть общей. Меня вот вымораживают абсолютно одинаковые функции для Клиентов и Поставщиков, которые опять же нужно параллельно суппортить.
Я видимо не застал жаркой дискуссии по поводу try..catch, но свято уверен что такая конструкция нужна. Нужны примеры? Их есть у меня. Если сидеть в песочнице, то хотя бы для того что бы залогировать ошибку. Ну а если мы выходим в люди, то это просто must have. Делаем отчёт в Excel, отчёт упал, Excel остался болтаться в памяти. Создаём подключение к любому внешнему источнику, что-то идёт не так и подключение остаётся висеть. Ну и т.д. и т.п. В M$ видимо тоже это понимают, поэтому вроде как с 2016 версии появился аналог (в NAV2017 точно есть) под названием TryFunction.
Ну и ещё, тут в соседней ветке обсуждают что же делать если код закроют? ООП может решить 90% проблем которые при этом могут возникнуть. Придётся конечно учиться этим пользоваться, ну так, прогресс не стоит на месте, и что бы нам оставаться на месте нужно бежать, а если мы хотим куда-то попасть, то бежать надо очень быстро.