Первые впечатления от программирования в D365FO

[fed]

Кстати - а вообще появился в D365/DAX2012 кастинг таблиц?
Можно писать if (common is CustTable) или (common as InventTable)?

[EVGL]

Цитата:

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

Кстати - а вообще появился в D365/DAX2012 кастинг таблиц?
Можно писать if (common is CustTable) или (common as InventTable)?

IS, похоже, не работает, т.е. от необходимости писать if (common.TableId == tableNum(LedgerJournalTrans)) не избавили. Я украсил свой код строкой journalTrans = common as LedgerJournalTrans, но есть ощущение, что этот оператор ничего полезного не делает.

Поправка: IS тоже работает.

[belugin]

Цитата:

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

journalTrans = common as LedgerJournalTrans, но есть ощущение, что этот оператор ничего полезного не делает.

Если вы подразумеваете, что в common точно должен быть journalTrans, то это даже вредно - в случае ощибки вы получите null вместо exception, и потом будете разбирваться с этим null, возможно в каком-то другом месте и выяснять, почему он получился.

Если же вы подразумеваете, что там может быть как journalTrans, так и что-то другое, то это полезно, так как в случае несоответсвия у вас будет null, который можно обработать, а не исключительная ситуация.

https://stackoverflow.com/questions/...vs-as-operator

[belugin]

Вроде да, но с особенностями
https://docs.microsoft.com/en-us/dyn.../xpp-operators



Tables
All tables inherit directly from the Common system table, unless they explicitly inherit from a different table. The Common table can't be instantiated. It doesn't exist in the underlying physical database. The Common table inherits from the xRecord class, but in a special way that isn't appropriate for the is keyword or the as keyword. When the as keyword is used to perform an invalid downcast among tables, the target variable references an unusable non-null entity. Any attempt to de-reference the target variable will cause an error that stops the program.

The is and as keywords and extended data types
Each extended data type has an Extends property. The style of inheritance that this property controls differs from the style of inheritance that the is and as keywords are designed for.

[trud]

Visual Basic .NET имеет такой же рейтинг как C#
Как такое вообще может быть?
что и кто интересно на нем разрабатывает. т.е. сколько я народу не знаю, никогда даже не слышал, сайт по поиску работы тоже 0 возвращает

[belugin]

Цитата:

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

Visual Basic .NET имеет такой же рейтинг как C#
Как такое вообще может быть?
что и кто интересно на нем разрабатывает. т.е. сколько я народу не знаю, никогда даже не слышал, сайт по поиску работы тоже 0 возвращает

Там методика описана. Вот еще индексы популярности:
https://en.wikipedia.org/wiki/Measur...larity#Indices

Во втором сверху у C# тоже 5

[AlexeyS]

смотря что и как считать, вот, например, интересная аналитика от stackoverflow

[belugin]

4 место https://insights.stackoverflow.com/s...ming-languages

[ax_mct]

Цитата:

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

Как вы думаете, операионная система под которой вы сейчас сидите это большой проект? На каком языке она написана?

https://www.tiobe.com/tiobe-index/ - пятого места мало?

Цитата:

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

4 место https://insights.stackoverflow.com/s...ming-languages

Наш (enterprise) большой проект это прежде всего прикладной проект где одна их характеристик - большая изменчивость. Скриптовые и интерпретируемые языки намного удобнее для программистов так где надо работать над требованиями.

В X++ все было RAD именно в силу интерпретации. Вся эта DLLность D365FO она не нужна в процессе разработки и билда.

Будущее C# подразумевалось как завоевание рынка Java на момент создания платформы .NET.
Чего не случилось за эти 15-20 лет. Замах был на рубль, а по сути произошел просто переход тех кто программировал под WIndows на VB и C++ MFC и пр. То есть обновление уже существующего своего рынка, в пределах уже лояльной к MS массы и не более того.

Вопрос в том насколько программирование в D365FO является современным программированием остается открытым Нормальные хипстеры не компилируют, это устарело лет на 30.

[belugin]

Цитата:

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

Наш (enterprise) большой проект это прежде всего прикладной проект где одна их характеристик - большая изменчивость. Скриптовые и интерпретируемые языки намного удобнее для программистов так где надо работать над требованиями.

Никаких интерпретируемых языков больше нет. Все компилируется. Джаваскрипт компилируется внутре. Для больших проектов к нему присобачивают cтатическую типизацию к php тоже прикручивают.

Цитата:

В X++ все было RAD именно в силу интерпретации. Вся эта DLLность D365FO она не нужна в процессе разработки и билда.
Вопрос в том насколько программирование в D365FO является современным программированием остается открытым Нормальные хипстеры не компилируют, это устарело лет на 30.

Компилируют, транспилируют, только прозрачно/на лету. Проблема в том, что AppSuite монолитный, а хипстеры в своих ангулярах разбивают свои приложения на модули.

PS. WebAssembly and the Death of JavaScript

[ax_mct]

Цитата:

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

Никаких интерпретируемых языков больше нет. Все компилируется.
...
Компилируют, транспилируют, только прозрачно/на лету. Проблема в том, что AppSuite монолитный, а хипстеры в своих ангулярах разбивают свои приложения на модули.

Ага. Все четко.
Только если у нас есть X++ в AX2012 и только потом папка с CIL как отдельная компиляция вне процесса разработки,
и есть D365FO где нам надо билдить в CIL при каждом изменении в процессе разработки,
то разница есть
несмотря на то что мы тоже как бы компилируем X++ (в P-code).

Почему же нам монолитность AppSuite не мешает в AX2012?
При том что "интерпретируемых языков больше нет".

[belugin]

Цитата:

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

Ага. Все четко.
Только если у нас есть X++ в AX2012 и только потом папка с CIL как отдельная компиляция вне процесса разработки,

Я тут писал пкрекодировщик для http://erpkb.info и вижу в процессе набора что-то не то. Оказалось, что тесты покраснели - я включил live unit testing и он мне покрасил в красный те строчки, которые выполнялись во время теста который я завалил. Интересное ощущение.

Еще когда году в 2003 начал писать на Eclipse, в начале было некоторое непонимание - там компиляция шла фоном и инициировалась по кнопке сохранить.

Цитата:

Почему же нам монолитность AppSuite не мешает в AX2012?
При том что "интерпретируемых языков больше нет".

Для виртуальной машины X++ он не монолитный, а состоит из кусочков, просто они более мелкие (уж не помню, классы или методы) и там немного другие условия целостности. Например есть циклические ссылки.

В Ax2012 есть проблемы, но другие. Попробуйте, например, не перекомпилировать
наследники и увидите какую-нибудь ерунду при выполнении даже если в самих наследниках ничего не изменилось. Ничего себе интерпретатор.

Цитата:

Будущее C# подразумевалось как завоевание рынка Java на момент создания платформы .NET.

Насколько я помню, сначала MS делал свою Java - причем очень тесно интегрированную в винду. Например, на ней очень удобно было делать COM-компоненты. Потом на этой почые они поругались с SUN, а потом возник .NET.

На кроссплатформенный рынок .NET стал выходить сравнительно недавно, после покупки Xamarin и разработки .NET Core.

Глянул в википедию - там написано, что это была часть .NET Strategy типа плана по захвату интернета?

[Logger]

2 Belugin
Вроде все правильно пишите, но тема разговора плавно ушла в сторону.

А по сути Ax_mct трижды прав:

Цитата:

Наш (enterprise) большой проект это прежде всего прикладной проект где одна их характеристик - большая изменчивость. Скриптовые и интерпретируемые языки намного удобнее для программистов так где надо работать над требованиями.

X++ в 2009-й ведет себя почти как скриптовый язык. Благодаря этому можно накатывать по живой базе. Т.е. можно быстро обновлять приложение не выгоняя всех юзеров и для обновления не надо стопить надолго аос. Изменчивость - наше все.

А с введение CIL в 2012-й всего-то добавили "маленькую" проблему - большой монолитный AppSuite. И все поломали.

Ну а дальше еще хуже.

[belugin]

Цитата:

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

X++ в 2009-й ведет себя почти как скриптовый язык. Благодаря этому можно накатывать по живой базе. Т.е. можно быстро обновлять приложение не выгоняя всех юзеров и для обновления не надо стопить надолго аос. Изменчивость - наше все.

Это проблема не компилируемости как таковой ИМХО а конкретного сочетания технологий.

В принципе, есть технология для hotswapping в .NET и она даже используется в Ax2012 . FED, правда, говорил, что глючит.

В современном мире, насколько я знаю, это решается не хотсвоппингом, а поднятием дополнительного инстанса сервиса с новой версии и рутингом новых запросов на него.

Но у меня в этом опыта нет. Кстати, интересно, есть ли какая-то гарантия согласовванности кода в Ax4 или если я загружу два новых класса, то может получиться ситуация, когда польователь работает одновременно со старой версией одного класса и новой - другого.

С этой точки зрения мне кажется ценнее получить согласованную версию кода, чем реализовывать хотсвоппинг. Как это реализовано в Ax сейчас я не знаю.

Еще вполне возможно что в других технологиях с хотсвоппингом лучше. Например edit and continue в вижуал студии для C# работает с большими ограничениями - в Java, говорят, их меньше.

[ax_mct]

Цитата:

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

Это проблема не компилируемости как таковой ИМХО а конкретного сочетания технологий.
...
Еще вполне возможно что в других технологиях с хотсвоппингом лучше. Например edit and continue в вижуал студии для C# работает с большими ограничениями - в Java, говорят, их меньше.

Согласен. Если подумать то CLR это подобная JVM вещь как process VM, и там и там запускается P-code (MSIL и Java Bytecode). И там и там компиляция. Но тут вопрос момента этой компиляции и тех самых сочетаний нюансов.

CLR требует компиляцию всего кода сразу и до. То есть взяли копировать Java/JVM но так и не поняли ее суть.

JVM компилирует частями и по потребности (в общем случае). Что позволяет оптимизацию при исполнении и более быструю разработку.

Та же Аксапта использовала JVM и такую "интерпретационную" компиляцию по частям что давало нам множество преимуществ в разработке. C необходимостью полной сборки MorphX был бы невозможен. А без MorphX это не 21 век.

P.S.
AppStore что сейчас обсуждается тоже душу не греет потому как скопирован опять таки с потерей сути. Действительно хочется увидеть клиента D365FO устанавливающего AppStore по кнопке. Это скорее анекдот.

[belugin]

Цитата:

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

CLR требует компиляцию всего кода сразу и до. То есть взяли копировать Java/JVM но так и не поняли ее суть.

Вы имеете ввиду компиляцию из исходного кода в промежуточный или из промежуточного в машинный?

Не могли бы вы привести ссылку для подтверждения своего утверджения?

Compilation by the JIT Compiler
JIT compilation converts MSIL to native code on demand at application run time, when the contents of an assembly are loaded and executed.

[ax_mct]

Цитата:

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

Вы имеете ввиду компиляцию из исходного кода в промежуточный или из промежуточного в машинный?

Не могли бы вы привести ссылку для подтверждения своего утверджения?

Compilation by the JIT Compiler
JIT compilation converts MSIL to native code on demand at application run time, when the contents of an assembly are loaded and executed.

Думаю что из промежуточного в машинный.
Промежуточный это P-code в X++, CIL в .NET, Bytecode (.class) в Java. Это файлы полученные из исходного кода и которые используются VM для перевода в машинный код (ngen и прочие не общие вещи не расматриваем).

Действительно получается что все упирается в реализацию JIT.
В Java их далеко не одна. Самый общий это HotSpot
https://ru.wikipedia.org/wiki/HotSpot
который сочетает и компилятор и интерпретатор.

Oracle HotSpot это больше 80% рынка JVM.

https://plumbr.io/blog/java/java-version-and-vendor-data-analyzed-2017-edition

Oracle HotSpot использует интерпретацию по умолчанию, и только потом компиляцию часто используемых методов.

Цитата:

HotSpot VM defaults to interpreting Java byte code. It compiles (JIT compilation) methods that runtime profiling determines to be "hot", that is, the methods that are executed for a predetermined number of times. JIT compliers are either client or server compilers.

https://docs.oracle.com/javase/9/jro...n.htm#JRHMG117

В CLR возможностей использования интерпретации в JIT - нет совсем.
А она таки для программистов удобнее и мы ее потеряли с D365FO.

[Ivanhoe]

Перефразирую мысль. Техническая проверка на компиляцию ничего не значит для конечного клиента (это и так подразумевалось для любой версии системы). Вопрос как это интегрировано в стандарт и как это пересекается с другими возможными решениями. Не на техническом уровне, а на логическом.

[trud]

Цитата:

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

Вопрос как это интегрировано в стандарт и как это пересекается с другими возможными решениями. Не на техническом уровне, а на логическом.

ну на логическом думаю вряд-ли у кого на 100%.
т.е. самое простое - в АХ есть возможность делать несколько накладных по заказу, т.е. вполне вероятно что часть решений просто не будет работать если это будут использовать, наверное это подразумевается фразой "глючная самописка"
т.е. решение предоставляет бизнес процессы, которые работают при "каких-то настройках". мс проверяет что эти процессы в принципе есть и хоть как-то работают(как часть процесса валидации)
уже дело клиента проанализировав выбрать

[fed]

Цитата:

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

т.е. решение предоставляет бизнес процессы, которые работают при "каких-то настройках". мс проверяет что эти процессы в принципе есть и хоть как-то работают(как часть процесса валидации)
уже дело клиента проанализировав выбрать

Ну если то есть - любой результат внедрения может быть представлен как вертикальное решение, потому что какие-то процессы при каких-то настройках у кого-то работают Не очень понятно, в чем же новизна AppSource - такие вертикальные решения существуют года с 2005ого.