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

[fed]

Цитата:

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

Это-то ладно, а вот callInventTrans(custTrans) считает что надо скастить касттранс к инвенттранс, а не ругнуться + нету каста на лету:

((CustTrans)common).accountNum

Мне, пожалуй что, нехватает запрета на неявное преобразование EDT. Просто я видел ситуации когда кто-то нечаянно код клиента в код поставщика присваивал или количество в стоимость. Единственное - вероятно надо было бы сохранить неявное преобразование результатов вычисления выражения.
Там, кстати, в D365 не сделали какую-то проверку Best practices на эту тему ?

[belugin]

Цитата:

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

Там, кстати, в D365 не сделали какую-то проверку Best practices на эту тему ?

Нет, такой проверки нет. Все примитивы вычисляются как базовые типы и так же сравниваются. Для Extensible Base Enums есть проверка на то, что они не превращаются в число и обратно.

[ax_mct]

Цитата:

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

Это-то ладно, а вот callInventTrans(custTrans) считает что надо скастить касттранс к инвенттранс, а не ругнуться + нету каста на лету:

((CustTrans)common).accountNum

Сommon реализован как класс. Object ->xRecord->Common.

Соответственно и InventTrans и CustTrans это его дети. Все в соответствии с ООП, полиморфизм.
Забавно

Нечего common использовать тем кто ругается на var

[belugin]

Цитата:

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

Сommon реализован как класс. Object ->xRecord->Common.

Соответственно и InventTrans и CustTrans это его дети. Все в соответствии с ООП, полиморфизм.

Я ругаюсь не на использование коммона, а на его тихий даункаст.

Попробуйте в C# написать

Object o;
List l;

o = l; // номально
l = (List)o; // номально
l = o as List; // нормально
l = o; // ошибка компиляции

[fed]

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

[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.

[AP-1055D]

Цитата:

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

но рекомендуют вот так:

var  x = 1;

Рекомендуют:

let  x = 1;

[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

[ax_mct]

Цитата:

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

Я ругаюсь не на использование коммона, а на его тихий даункаст.

Попробуйте в C# написать

Object o;
List l;

o = l; // номально
[B]l = (List)o; // номально[/B]
l = o as List; // нормально
[B]l = o; // ошибка компиляции[/B]

Вспоминая ошибки молодости 15 летней давности
InventTrans inventTrans = _custTrans; // должна быть ошибка компиляции
InventTrans inventTrans = (СustTrans)common; // должна быть ошибка компиляции

Как понимаю вопрос в таком downcast
void foo(Common _commonCustTrans)
{
InventTrans inventTrans = (InventTrans)_commonCustTrans;
}

Тут ничего не поделать, все законно. Имена переменных ничего не значат, а передается родитель.
void foo(Parent _childA)
{
ChildB childB = (ChildB)_childA;
}

А вот если передавать конкретный тип, а не common, то да можно жаловаться
void foo(ChildA_childA) // вместо common например CustTable _custTable
{
ChildB childB = (ChildB)_childA; // обязана ругаться
}

[belugin]

Цитата:

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

InventTrans inventTrans = (СustTrans)common; // должна быть ошибка компиляции

Это она в аксапте есть, но нет способа строго привести к другому типу не объявляя дополнительных переменных.

Цитата:

Как понимаю вопрос в таком downcast
void foo(Common _commonCustTrans)

Я имел ввиду это:

void foo(CustTrans _custTrans)
{
}

Common x;
foo(x);

[ax_mct]

Цитата:

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

Это она в аксапте есть, но нет способа строго привести к другому типу не объявляя дополнительных переменных.



Я имел ввиду это:

void foo(CustTrans _custTrans)
{
}

Common x;
foo(x);

Ага. А должен быть warning в VS ?
Manager extends Person;
Worker extends Person;

void callWorker(Worker _worker){};

Person person;
callWorker(person);

[belugin]

Должен быть compiler error как в С#, например, пока не будет явного каста.

[ax_mct]

Цитата:

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

Должен быть compiler error как в С#, например, пока не будет явного каста.

Понял. Спасибо. Как-то в голову не приходило что X++ компилятор в VS отличается от С# компилятора.

Как-то ассоцировалось с VB.NET vs С#.NET где по-сути только синтаксис отличия, а тут как бы не X++.NET, а типа интеграция для поддержки старого X++ кода.

Наверное эта интеграция и жрет все ресурсы

А где можно почитать впечатления клиентов от работы в D365FO с точки зрения быстродействия? HTML он там тоже может быть прожорливый, или кэшируется слой презентации как-то?

[belugin]

Цитата:

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

Как-то ассоцировалось с VB.NET vs С#.NET где по-сути только синтаксис отличия, а тут как бы не X++.NET, а типа интеграция для поддержки старого X++ кода.

Да, это для обратной совместимости. Он очень похож на то, что в 2012 по своим свойствам.

Цитата:

Наверное эта интеграция и жрет все ресурсы

В отличие от 2012 он переписан на C#, то есть код сравнительно свежий.
В отличие от 2012 он генерирует сборки, то есть такая ситуация, что часть кода не компилируется, не позволяется.
В отличие от C#, есть просто гигантская сборка под названием Application Suite и применены всякие трюки чтобы билдить и юзать ее частично.
Еще в отличии от C# код хранится в XML для поддержки слоёв .
Кусочек который я трейсил при помощи PerfView занимался, в-основном, дересерелизацией метаданных из этого XML. Возможно там есть задел для ускорения.

[ax_mct]

Цитата:

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

В отличие от 2012 он переписан на C#, то есть код сравнительно свежий.
В отличие от 2012 он генерирует сборки, то есть такая ситуация, что часть кода не компилируется, не позволяется.
В отличие от C#, есть просто гигантская сборка под названием Application Suite и применены всякие трюки чтобы билдить и юзать ее частично.
Еще в отличии от C# код хранится в XML для поддержки слоёв .
Кусочек который я трейсил при помощи PerfView занимался, в-основном, дересерелизацией метаданных из этого XML. Возможно там есть задел для ускорения.

Конвертировать X++ код в C# мне представляется куда менее трудоемкой задачей чем то что сделано.

Хранить в .cs., поддержку слоев реализовать структурой файловой системы где хранятся эти .cs. (Tables\USR\CustTable.cs)

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

[belugin]

Цитата:

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

Конвертировать X++ код в C# мне представляется куда менее трудоемкой задачей чем то что сделано.

Резeльтат будет в простых случаях многословнее и в каких-то случаях тормознее (LINQ) и надо будет наделать дополнительных правил проверски, на корректность этого LINQ.

Еще непонятно, что делать с гигантским монолитным ApplicationSuite.

Цитата:

Хранить в .cs., поддержку слоев реализовать структурой файловой системы где хранятся эти .cs. (Tables\USR\CustTable.cs)

Я бы просто хранил в системе контроля версий по веткам.

Цитата:

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

Они недалеко от Редмонда.

P.S. The future of C#

[ax_mct]

Цитата:

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

Резeльтат будет в простых случаях многословнее и в каких-то случаях тормознее (LINQ) и надо будет наделать дополнительных правил проверски, на корректность этого LINQ.

Еще непонятно, что делать с гигантским монолитным ApplicationSuite.

Я бы просто хранил в системе контроля версий по веткам.

Они недалеко от Редмонда.

P.S. The future of C#

https://youtu.be/QZ0rWLaMZeI?t=1m
"Once again, we happy to announce, this is becoming traditional, C# has a future and we're going to talk about it".
И им смешно и аудитории

Гигантский монолитный ApplicationSuite это кстати демонстрация недостатка компилируемого языка на больших проектах. Отчасти одна из причин того что C# как имел светлое будущее 15 лет назад так к этому будущему до сих пор и стремится.

Ну не знаю, мне кажется сделать конвертор X++ в С# задача технически более осмысленная чем городить все эти прослойки. Но политически да, "тот же код с другим интерфейсом" была такая задача.

Вся для удобства и счастья X++ программиста, и код X++ тот же и абстракция от UI, и точки расширения где хочешь, и массаж плеч и стоп...Спасибо MS за заботу хочется сказать

[belugin]

Цитата:

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

Гигантский монолитный ApplicationSuite это кстати демонстрация недостатка компилируемого языка на больших проектах.

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

Цитата:

Отчасти одна из причин того что C# как имел светлое будущее 15 лет назад так к этому будущему до сих пор и стремится.

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

[trud]

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