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

[rmv]

Тогда уже Javascript, зачем мелочиться

[Predatore]

Цитата:

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

Тогда уже Javascript, зачем мелочиться

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

[artkashin]

Цитата:

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

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

хм.. интересно, почему этот интерфейс объявления переменных "устарел"? на мой взгляд, это одна из фишечек Нава. И переменные типизированные, и код избавлен от хлама. Это одна из фишек, которая позволяет при соблюдении стандартов разработки просто читать код и понимать, как он работает.
Смотришь код Аксапты, а там 30% строк - объявление переменных, 25-40% - обвертки, в виде try catch и exception и всякими ttsbegin с ttscommit, ну а собственно бизнес-логика в оставшихся 30%, дай бог. И она может быть написана как угодно сложно и зачастую без дебаггера не обойтись - ибо там может быть и переопределенные наследниками методы и прочие плюшки для программистов, которые на самом деле - ад для поддержки.

Я это говорю не в претензию к Акс - там много других плюшек, отсутствующих в NAV, да и не так хорошо я ее знаю - а к тому, что вы недооцениваете эту возможность скрывать объявленные переменные с глаз долой. Наряду с готовыми блоками триггеров, в которых просто остается написать свой код, это - одна из приятнейших особенностей навика. Вам не надо писать кучу кода в каком нибудь методе validateWrite для обработки изменения цены, изменения кучи других полей. Вы всегда можете найти код в onValidate условного "Unit Price".

Все-таки, почему же это считается устаревшим, а смешивание объявления переменных с кодом - модным?
на мой взгляд, тут прямая аналогия с css и html.

[Predatore]

Цитата:

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

хм.. интересно, почему этот интерфейс объявления переменных "устарел"? на мой взгляд, это одна из фишечек Нава. И переменные типизированные, и код избавлен от хлама. Это одна из фишек, которая позволяет при соблюдении стандартов разработки просто читать код и понимать, как он работает.
Смотришь код Аксапты, а там 30% строк - объявление переменных, 25-40% - обвертки, в виде try catch и exception и всякими ttsbegin с ttscommit, ну а собственно бизнес-логика в оставшихся 30%, дай бог. И она может быть написана как угодно сложно и зачастую без дебаггера не обойтись - ибо там может быть и переопределенные наследниками методы и прочие плюшки для программистов, которые на самом деле - ад для поддержки.

Я это говорю не в претензию к Акс - там много других плюшек, отсутствующих в NAV, да и не так хорошо я ее знаю - а к тому, что вы недооцениваете эту возможность скрывать объявленные переменные с глаз долой. Наряду с готовыми блоками триггеров, в которых просто остается написать свой код, это - одна из приятнейших особенностей навика. Вам не надо писать кучу кода в каком нибудь методе validateWrite для обработки изменения цены, изменения кучи других полей. Вы всегда можете найти код в onValidate условного "Unit Price".

Все-таки, почему же это считается устаревшим, а смешивание объявления переменных с кодом - модным?
на мой взгляд, тут прямая аналогия с css и html.

Всё очень просто. Спрятанное объявление переменных спрятано. Уж простите за тавтологию и капитанство.
Ну а теперь почему это так плохо. Начнём с того что это примерно в 2-3 раза увеличивает время объявления переменных. При этом не получается, как Вы выразились "просто читать код", потому что не понятно что за переменные, локальные они или глобальные, да и переменные ли? А может поля? Или даже функции? Именование частично решает это проблему, но порождает другую, имена становятся перегруженными, а хуже того, в коде плодится и множится винегрет из "стандартов разработки".
И почему "смешивание"? Объявление переменных это тоже код, его тоже нужно читать, а ещё не плохо бы по нему искать и править его, что опят таки невозможно с такой "фишкой". И такой код, это не модно, это удобно, быстро и легче поддерживать.
А если Вас пугает ручной набор, так Вы видимо никогда не кодили в Студии. Я кроме прочего пишу и на шарпе тоже, так вот, в Студии я в ручную набираю на 70-80% меньше чем в НАВ. А на объявление переменных я трачу и того меньше времени.
Фантастика? Вовсе нет, просто редактор даже 2016-ого (2017 пока ничем не отличается, но держим кулачки) НАВа устарел ещё 20 лет назад. И слава Богу его отправляют на покой.

[artkashin]

Цитата:

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

Ну а теперь почему это так плохо. Начнём с того что это примерно в 2-3 раза увеличивает время объявления переменных.

хм. Вот вы утверждаете в 2-3 раза увеличивает. А я говорю, сокращает в 2-3 раза, особенно, если вы пишете код функции или объекта который не помещается на одной странице. Ctrl-G (Ctrl-L), F3, имя переменной, тип. Готово к использованию. Курсор при этом ни на секунду не изменил своего положения. Продолжаешь писать код в том же месте.
Да, справедливости ради, Ctrl-G появился в NAV2016. Раньше была магическая комбинация alt-V + 3-4 клавиши вверх.
В любом случае, при разработке, мышка не используется - если речь идет не об отчетах. Производительность без использования мышки, если что, обычно в разы выше чем с ней.
Чтобы объявить переменную в студии, извините, но во избежание бардака вам придется идти в начало метода/функции и объявлять ее там. А потом возвращаться обратно. Все равно выделяется место где эти переменные объявляются (обычно, в начале). А объявлять переменные вперемежку с кодом в большинстве случаев не комильфо, даже если язык программирования вам это позволяет. И пусть это тоже можно сделать без мышки, но потеря фокуса - при разработке - это как потеря концентрации.

Цитата:

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

При этом не получается, как Вы выразились "просто читать код", потому что не понятно что за переменные, локальные они или глобальные, да и переменные ли? А может поля? Или даже функции? Именование частично решает это проблему, но порождает другую, имена становятся перегруженными, а хуже того, в коде плодится и множится винегрет из "стандартов разработки".

Стандарты разработки, хотите вы того или нет, будут всегда, если вы не работаете один. Правильное именование объектов, все-таки, позволяет читать код без проблем. SalesInvHeader - это, извините, таблица 112. А если какой-то нехороший человек написал, что это boolean, то конечно это факап, и расстрелять надо такого нехорошего человека. Это тоже самое, что в Cях

#define TRUE FALSE

В любом случае, стандартный код "читается" легко.

Цитата:

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

И почему "смешивание"? Объявление переменных это тоже код, его тоже нужно читать, а ещё не плохо бы по нему искать и править его, что опят таки невозможно с такой "фишкой". И такой код, это не модно, это удобно, быстро и легче поддерживать.

Вопрос в частоте. Вам часто приходится править определение типа переменных?
Выгрузите объект в текст - ищите, правьте там. Ведь по-сути, весь этот новый AL - это объекты, выгруженные в текст. Отличий - минимум. Только, если раньше структуру этого текстовичка среда Нава поддерживала сама, теперь это предлагается переложить на мои плечи.
А в моей практике, изменить тип переменной требуется крайне редко и к подобной процедуре я прибегаю дай бог, раз в полгода.
А насчет "быстро и легче поддерживать". Каждому - свое.

Кстати, могли бы просто добавить к текущему виду кода возможность просмотра/правки объекта в текстовом виде, не выходя из редактора кода - и вашим и нашим.
Т.е. смотришь на стандартное окошко с кучей триггеров на таблице onValidate, 99% из которых - пусты, щелкаешь какой-нибудь Ctrl-T, и рядышком открывается этот же объект, но в тексте.

Цитата:

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

А если Вас пугает ручной набор, так Вы видимо никогда не кодили в Студии. Я кроме прочего пишу и на шарпе тоже, так вот, в Студии я в ручную набираю на 70-80% меньше чем в НАВ. А на объявление переменных я трачу и того меньше времени.

Я полагаю, что все когда-то да кодили в студии.
Меня пугает, что появляется возможность ручного набора там, где было все жестко фиксировано, и меня,например, эта жесткая фиксация устраивала - она увеличивала мою производительность. И сильно.
Там где можно руками набрать, можно руками и не набрать, или набрать неправильно.
Что будет, если я не напишу в codeunit из примера триггер OnRun? или назову его OnWalk?

trigger OnRun();

Триггер OnRun может быть написан в середине КЮ из ста функций? Мне его искать надо будет? он не всегда будет в начале?
что будет, если я напишу (CODEUNIT.RUN(70051001, Customer) а триггера OnRun нет? Runtime error?

Цитата:

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

Фантастика? Вовсе нет, просто редактор даже 2016-ого (2017 пока ничем не отличается, но держим кулачки) НАВа устарел ещё 20 лет назад. И слава Богу его отправляют на покой.

Меня пугает то, что предлагают в замен. Красивую студию, но работать придется сугубо с текстовичком? Посмотрим, конечно.
Среда разработки устарела, это безусловно, я с этим и не спорил.
Хотя меня, в большинстве случаев, она, на удивление, устраивала.
И вот интерфейс объявления переменных - это как раз то, чему Студии надо Учиться у навика, а не наоборот.

[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% проблем которые при этом могут возникнуть. Придётся конечно учиться этим пользоваться, ну так, прогресс не стоит на месте, и что бы нам оставаться на месте нужно бежать, а если мы хотим куда-то попасть, то бежать надо очень быстро.