DeniZone: The future of X++

[gl00mie]

Цитата:

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

Вообще - еще раз перечитал все эти дискуссии по поводу перехода на CLR

В дополнение к этому можно еще раз послушать (или почитать), о чем говорится в исходной презентации.

Цитата:

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

и нашел только два довода в пользу того, почему это хорошо: 1. Не надо учить новый язык программирования для новых разработчиков. Эти наивные люди до сих пор думают что разработчики X++ используют только для создания новых форм и интеграции с внешними приложениями. Реально - X++ учиться за месяц, может - три. Все остальные годы уходят на изучение прикладной логики системы. Резюме - аргумент не катит.

Во-первых, Х++ учить все же дольше месяца-трех, потому что в нем очень много мелких "особенностей", совершенно неочевидных и непонятных для тех, кто до этого учил С++/C#/VB... Во-вторых, и об этом говорилось в исходной презентации, не каждый сторонний разработчик захочет вообще учить X++. Если человек хорошо знает тот же C# и .NET, если фанатеет от возможностей последних версий Visual Studio, может, сам пишет какие-нить шаблоны под T4, то его будет сложно уговорить изучить язык, который хоть и похож на Java, но все же довольно специфичен сам по себе и при этом используется в одной-едиственной системе (как правильно было замечено, функционал системы еще тоже придется изучать). Плюс к этому разработка ведется не в VS, где сейчас пишется практически всё - от сайтов и баз данных до драйверов устройст, а в собственной среде с весьма "недогадливым" по сравнению с VS intellisense'ом, с глюкавеньким отладчиком, не умеющим останавливаться на последней фигурной скобке метода, чтобы показать, какое именно значение тот вернет, или, тем более, показывать, что происходит в классах ядра, или ставить там точки останова ("все-таки где же эта [censored], которая выставляет allowEdit() на datasource'е?!"). Даже если писать код "сбоку" на том же C#, взаимодействуя с AX через Business Connector, то опять же, приходится дергать приложение фактически с использованием одного из инструментов отражения, без какой-либо поддержки intellisense, постоянно подсматривая числовые значения енумов либо дублируя их в своем коде - в общем, удовольствие то еще.
А в случае перехода на CLR, как отмечалось в той же презентации, новым разработчикам не надо будет месяц-три-шесть учить X++, который им больше нигде не пригодится. Вместо этого работодатели смогут говорить им: вы будете работать в привычной среде, использовать .NET, развиваться как разработчик C# (например) - плюс к этому еще и приобретете опыт разработки бизнес-приложений. Мне сложно прогнозировать, как это может отразиться на рынке труда программистов Axapta, но для работодателей определенный плюс в этом, мне кажется, есть. Кроме того, даже интеграция с приложением может упроститься за счет отказа от Business Connector и от работы с классами и таблицами через отражение. Вон, в презентации подцепили к проекту 64-мегабайтную сборку с кодом всех классов и таблиц приложения AX - и все они для разработчика стали, как на ладони, с поддержкой intellisence и всего прочего.

Цитата:

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

2. Ускоряется работа сборщика мусора. Эээ. Возможно. А если в native code компилировать - она ведь еще бы сильнее выросла ? Чтож вы ребята на p-code остановились-то?

Не знаю, как в 4-ке или в 2009-й изменился p-код, я не ковырял, а в 3-ке его реализация очень и очень простая: есть таблица из 256 возможных кодов (в общем случае каждому ключевому слову языка, такому как for, while, if, select, forceplaceholders и т.д. соответствует свое однобайтовое значение, плюс еще операторы и проч.), причем реально используются, может, сотни полторы значений, есть массив указателей на функции-обработчики отдельных кодов (неиспользуемым кодам в массиве указателей соответствует ссылка на один и тот же обработчик некорректного байт-кода). Соответственно, интерпретатор считывает байт p-кода, увеличивает "указатель команд" (по аналогии с EIP в x86), затем использует считанный код как индекс в массиве указателей на функции-обработчики и вызывает нужную функцию; та, в зависимости от реализуемой операции, извлекает из потока p-кода дополнительные аргументы, соответственно увеличивая "указатель команд", либо не делает этого, если аргументы не предусмотрены, и собственно делает что-то полезное. Да, есть витиеватый код поддержки "CQL" (так вроде в ядре именуется реализованное подмножество SQL), есть менеджер управления памятью, сборщик мусора, подсчет ссылок на объекты и т.д., но сама по себе стековая машина, обрабатываютщая p-код, выглядит довольно просто. Если бы пришлось компилировать код приложения в машинные инструкции, то мало того, что пришлось бы реализовывать на порядки более сложную логику работы компилятора, реализовывать в коде RTTI и проч., так еще и интерфейс между кодом приложения и сервисами ядра (поддержка CQL, управление памятью и проч.) усложнился бы весьма существенно. Я уже не говорю о том, что пришлось бы реализовывать полноценный отладчик с поддержкой выполнения машинного кода x86 (тут можно вспомнить применяемую компиляторами для оптимизации по скорости перегруппировку инструкций x86 для задействования нескольких конвейеров обработки команд в процессоре). Кроме того, это в любом случае не решило бы озвученную в презентации проблему с плохой масштабируемостью системы управления памятью, использующей детерминированную сборку мусора. В общем, слишком много сложностей с более чем весомыми затратами на реализацию и неопределенным выйгрышем в производительности. В презентации тоже звучали мысли на эту тему:

• Нам не следует самим нести все затраты, связанные с поддержкой и развитием всей инфраструктуры, когда есть такие отличные вещи, как .NET, и Visual Studio, и LINQ.
• На данный момент в нашем приложении появились опеределенные проблемы, связанные с тем, что разработчики начали использовать X++ так, как мы совершенно не расчитывали на момент разработки языка.
• Наша команда X++ довольно малочислена, и мы знали, что нам никогда бы не выделили финансирование на полное переписывание компилятора под создание управляемого кода, от начала до конца, поэтому мы решили пойти на небольшой компромис. Таким образом, весь стек инструментов разработки, который у нас есть и который использовался и тестировался на протяжении 15 лет, остается в полной неприкосновенности, в нем не меняется ни строчки исходного кода. Так что нам не нужно проводить обширное тестирование всего кода X++ во всем мире на совместимость с нашей разработкой.

Заметьте: "красноглазики" вовсе не просто так от нечего делать начали заниматься вопросами детерминированной сборки мусора в системе управления памятью AX. Возникла проблема с производительностью, в команду X++ поступил запрос разобраться в причине и как-то решить проблему. Они разобрались и выяснили, что все упирается систему управления памятью, которая начинает тормозить на очень большом количестве объектов в памяти. Решить собственными силами проблему не удалось - вот и попробовали задействовать в некотором смысле стороннее решение.

Цитата:

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

В общем - мое резюме: Красноглазики добрались до ядра Аксапты. Как и зачем она используется они слабо понимают, но явно присутствует желание за казенный счет попрограммировать чего-то большое и светлое, "для души"...

Ну, поживем - увидим. В любом случае, думаю, раньше AX "2013" это все в ядре не появится.

[fed]

Я пожалуй что расскажу об одной любопытной вещи. До того как я пришел на работу в MS (в конце 2006 года, буквально за две недели до моего первого рабочего дня в MS), меня знакомый затащил на встречу питерской группы .net users group. И там выступал и показывал свой продукт один мой будущий (на тот момент) коллега, который из Питера перебрался работать в датском центре разработки.
А показывал он очень простую вещь - редактор форм Аксапты внутри VS, редактор кода Аксапты внутри VS и, кажется, даже компилятор X++ внутри VS. На провокационные вопросы - типа "Сделаете ли вы X++ managed языком", этот товарищ не отвечал, с присказками "Не могу, типа NDA и все дела". Аксаптеров на этом мероприятии кроме меня не было, а разработчикам .net увиденное было тяжело осмыслить, так что все это прошло мало заметно.

Так что то что в ролике с Channel 9 было показано, я видел, без малого три года назад. Потом я про этот проект за два с половиной года работы в MS ничего не слышал, и в целом полагал что его похоронили.
И весь мой скептицизм по поводу перехода на .net вызван как раз тем, что если проект три года развивался, то непонятно почему за три года прогресс такой слабый (судя по тому что номер версии Аксапты, в которой это выйдет они не называют). Если проект три года был заморожен как неперспективный, то не очень понятно, почему они решили что у них в этот раз получиться...
Ну и кстати я всех этих восторгов по поводу среды VS не разделяю. Visual Studio - замечательная среда разработки БОЛЬШИХ проектов. Типа когда мы сначала проектируем иерархию классов, создаем файлы заголовков, разрабатываем сервисы, рисуем зависимости для компиляции, делаем публикацию в веб-сервисы и тп. А в Аксапте - 90% доработок - это пара строк в нужном методе. И как-то меня пугает мысль что мне для этого придется этот метод checkoutить из репозитария, править, checkinить, компилировать все приложение, деплоить серверные веб-сервисы, деплоить клиентское приложение и только после этого получать результат.

Я, если позволите, еще раз приведу услышанные аргументы перехода на .net:
1. Легкость обучения/доступность специалистов. Затраты на обучение действительно могут СЛЕГКА снизиться. Типа готовность специалиста будет наступать не через 18-25 месяцев, а эдак месяца на 2 раньше. Но это не принципиально.
2. Более совершенная среда разработки VS. Она более совершенная - но только для случая РАЗРАБОТКИ с ноля, а не быстрой доработки. Еще не известно в чем именно аксаптерские решения проще разрабатывать - в убогой но компактной среде разработки Аксапты или в богатой, но тяжелой среде разработки VS.
3. Оптимизация затрат на разработку среды исполнения X++. Возможно что это действительно так.А возможно - и нет. Как раз то что я спустя почти три года вижу примерно тот же прототип что и раньше, наводят меня на мысль что доработать прототип до промышленной системы довольно нелегко...

[belugin]

Цитата:

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

А показывал он очень простую вещь - редактор форм Аксапты внутри VS, редактор кода Аксапты внутри VS и, кажется, даже компилятор X++ внутри VS.
...
Так что то что в ролике с Channel 9 было показано, я видел, без малого три года назад.

И что же из этого было в ролике и нет ли чего-то в ролике, что не было на презентации

[polygris]

Полностью согласен с fed. Пусть Visual Studio остается тяжелой средой разработки для крупных разработок. А в аксе реально нужно править всего несколько строчек кода.
Лучше бы МС допилил бы Intellisense в редакторе, да добавил примочки для девелопера - например таких какие есть в виде плагинов к Tabax.

Не понимаю какую выгоду получит разработчик или покупатель от того что код будет компилится в .NET?

[belugin]

Цитата:

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

Пусть Visual Studio остается тяжелой средой разработки для крупных разработок.

По какой метрике VS2008 тяжелее Ax2009?

[gl00mie]

Цитата:

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

Пусть Visual Studio остается тяжелой средой разработки для крупных разработок. А в аксе реально нужно править всего несколько строчек кода.

Если вам в Аксапте нужно по работе править всего несколько строчек кода, то могу лишь порадоваться за вас - наверняка в опросе Как сильно модифицировано ваше приложение Аксапты? вы выбрали один из первых вариантов ответа.

Цитата:

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

Лучше бы МС допилил бы Intellisense в редакторе, да добавил примочки для девелопера - например таких какие есть в виде плагинов к Tabax.

Такое ощущение, что доводы членов команды X++, приведенные в обсуждаемом видео на channel9, вами не были восприняты Для верности я продублировал часть доводов в этой теме. Еще раз:

• Разработчики ядра Аксапты не хотят допиливать IntelliSense, отладчик и прочие средства для разработчиков, потому что все это уже есть в VS.
• Они не хотят доделывать тот же редактор кода самостоятельно, поэтому для AX6 взяли движок редактора из VS.
• Они не хотят самостоятельно бодаться с проблемами производительности нынешнего менеджера памяти в ядре, в которые они уперлись, потому что для их решения нужно пойти на фундаментальные изменения - отказ от детерминированной сброки мусора. А отличный менеджер памяти с недетерминированной сборкой мусора уже есть в CLR.

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

[fed]

Цитата:

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

Еще раз:

• Разработчики ядра Аксапты не хотят допиливать IntelliSense, отладчик и прочие средства для разработчиков, потому что все это уже есть в VS.
• Они не хотят доделывать тот же редактор кода самостоятельно, поэтому для AX6 взяли движок редактора из VS.
• Они не хотят самостоятельно бодаться с проблемами производительности нынешнего менеджера памяти в ядре, в которые они уперлись, потому что для их решения нужно пойти на фундаментальные изменения - отказ от детерминированной сброки мусора. А отличный менеджер памяти с недетерминированной сборкой мусора уже есть в CLR.

Нет - это все замечательно, ни с чем не поспоришь. Но дело в том, что там люди еще рассуждали о том что неплохо бы вместо X++ использовать C#, для удаленных вызовов использовать веб-сервисы и вообще Аксапту сделать более stateless.

Если эти замечательные глубокомысленные люди знают КАК все это сделать с разумным уровнем гемора для внедренцев, причем в ближайшие лет 5, а не к моменту смерти осла из притчи - хотелось бы чтобы они все это ОЗВУЧИЛИ.

Если же все это - их фантазии, то наверное не стоит будоражить публику сказками о не существующей в данный момент технологии. А если она существует, но рассказать они о ней не могут, то нефиг было воду мутить раньше времени...

[fed]

Ну собственно я поэтому и написал, что поддержка С# - это фича предназначенная для поддержки продаж. Чтобы можно было клиентским айтишникам гордо сказать: Смотрите - ее можно программировать на C# ! Вашим разработчикам не придется переучиваться !
Ну а потом выясниться что все равно вся полезная логика написана на X++ и никто ее на C# переписывать не собирается. Соответственно - все равно придется X++ изучать.

Просто до того как я не позанимался слегка продажами, я не понимал что часть фич в программном продукте пишется не для внедрения, а для демонстрации во время продаж. Например, явно к этой категории относиться модуль Balanced Scorecard. Ну а глядишь в версии 7 еще и какое-нить Visual Studio Integration для этого напишут...

[mifi]

А для чего интересно еще пишутся фичи в программном продукте, если не для поддержки продаж? Мне известно только две модели зарабатывания денег на ПО - деньги от продаж и/или деньги от поддержки.
Просьба озвучить третью
И что плохого в том, что программисты C# получат классную интеграцию с АОT?

[fed]

Цитата:

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

А для чего интересно еще пишутся фичи в программном продукте, если не для поддержки продаж? Мне известно только две модели зарабатывания денег на ПО - деньги от продаж и/или деньги от поддержки.
Просьба озвучить третью
И что плохого в том, что программисты C# получат классную интеграцию с АОT?

Ну ты ведь знаешь как микрософт удоволетворенность продуктом замеряет ? И если удовлетворенность низкая, то какой-то службе может попасть по первое число Причем делает это Микрософт не из спортивного интереса и любви к пользователям, а потому что удволетворенность сейчас - это фактически долгосрочный прогноз выручки. Чем ниже удовлетворенность, тем больше шансов что клиент соскочит и годика через три будет выручку конкурентам приносить. Любые Sales Oriented Features - это создание ложных ожиданий от продукта. А ложные ожидания - низкая удовлетворенность. Низкая удовлетворенность - шансы того что клиент соскочит. Соответственно - любая sales feature - это попытка сорвать с клиента немножко денег СЕЙЧАС, в ущерб ДОЛГОСРОЧНЫМ перспективам получать с клиента деньги регулярно.

По поводу того, что программисты C# получат классную интеграцию с AOT. А рыночный спрос на это есть ? Я вот почти 9 лет аксапту внедряю, и как то мне это пока не понадобилось. А бабла микрософт на эту интеграцию не мало потратит. И есть шансы что какие-нибудь фичи, которые мне как внедренцу нужны - не будут реализованы из за этого. Это-то и злит в общем.
Если у Микрософта лишние деньги есть - так лучше бы попробовали поверх MS OLAP написать клиента нормального, бюджетирование и синтегрировали бы все это с Аксаптой например... От этого на проектах куда больше было бы пользы чем от этой интеграции с .net

[mifi]

Цитата:

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

Ну ты ведь знаешь как микрософт удоволетворенность продуктом замеряет ? И если удовлетворенность низкая, то какой-то службе может попасть по первое число Причем делает это Микрософт не из спортивного интереса и любви к пользователям, а потому что удволетворенность сейчас - это фактически долгосрочный прогноз выручки. Чем ниже удовлетворенность, тем больше шансов что клиент соскочит и годика через три будет выручку конкурентам приносить. Любые Sales Oriented Features - это создание ложных ожиданий от продукта. А ложные ожидания - низкая удовлетворенность. Низкая удовлетворенность - шансы того что клиент соскочит. Соответственно - любая sales feature - это попытка сорвать с клиента немножко денег СЕЙЧАС, в ущерб ДОЛГОСРОЧНЫМ перспективам получать с клиента деньги регулярно.

По поводу того, что программисты C# получат классную интеграцию с AOT. А рыночный спрос на это есть ? Я вот почти 9 лет аксапту внедряю, и как то мне это пока не понадобилось. А бабла микрософт на эту интеграцию не мало потратит. И есть шансы что какие-нибудь фичи, которые мне как внедренцу нужны - не будут реализованы из за этого. Это-то и злит в общем.
Если у Микрософта лишние деньги есть - так лучше бы попробовали поверх MS OLAP написать клиента нормального, бюджетирование и синтегрировали бы все это с Аксаптой например... От этого на проектах куда больше было бы пользы чем от этой интеграции с .net

Вероятность что клиент соскочит - да, есть. Но при внедрении любой ERP системы это в 99% случае происходит по трем причинам - политика, политика, политика. А если система не содержит пару "sales oriented features" клиент соскочит намного раньше - во время тендера. И будет внедрять другую систему, в которой реальных проблем может быть еще больше.
По поводу того, кто сколько лет внедряет и кому оно понадобилось - тут нужно различать работу со стороны клиента и со стороны партнера. Клиентские разработчики в большинстве случаев клепают отчеты и делают всякую интеграцию. Зачем для решения этих задач знание X++, гораздо проще и дешевле нанять C# разработчика который все это ссделает в Visual Studio

[fed]

Цитата:

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

Вероятность что клиент соскочит - да, есть. Но при внедрении любой ERP системы это в 99% случае происходит по трем причинам - политика, политика, политика. А если система не содержит пару "sales oriented features" клиент соскочит намного раньше - во время тендера. И будет внедрять другую систему, в которой реальных проблем может быть еще больше.
По поводу того, кто сколько лет внедряет и кому оно понадобилось - тут нужно различать работу со стороны клиента и со стороны партнера. Клиентские разработчики в большинстве случаев клепают отчеты и делают всякую интеграцию. Зачем для решения этих задач знание X++, гораздо проще и дешевле нанять C# разработчика который все это ссделает в Visual Studio

Ну если уж уходить в политику - то мнение айтишников, обычно, является далеко не решающим при продаже. Так что в качестве sales oriented feature проще было бы, ну скажем сделать интеграцию с Bing Maps Она, правда, тоже реально бесполезна, но ее хотя бы директору по логистике можно показать. Так что если считать C# сейловым функционалом - то это не самое выгодное вложение денег. Затраты большие - а реальная польза - красноглазикам показать, которых все равно никто не спрашивает.

Ну а насчет клиентских программистов - дык уже счас можно отчеты на SSRS клепать и туда вставочки на C# писать. Правда чтобы человек без знания Аксапты смог сложный отчет написать (а простые ведь и без программинга можно на коленке нарисовать), то придется ему детальную спецификацию писать. Которую проще самому запрограммировать чем для другого написать

[belugin]

Цитата:

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

Любые Sales Oriented Features - это создание ложных ожиданий от продукта.

А не может так быть, что сейчас в блогах и таких интервью рассказываются про сейлс-ориентед фичах будущих версий, а если бы ты знал все подробности, то у тебя было бы несколько другое мнение?

Почему так получилось, что про C# Татаринову был задан вопрос, а про бюджет - нет?

Кстати, ты знаешь про PowerPivot?

[fed]

Цитата:

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

А не может так быть, что сейчас в блогах и таких интервью рассказываются про сейлс-ориентед фичах будущих версий, а если бы ты знал все подробности, то у тебя было бы несколько другое мнение?

Почему так получилось, что про C# Татаринову был задан вопрос, а про бюджет - нет?

Кстати, ты знаешь про PowerPivot?

Про PowerPivot - не знаю, но посмотрю.
А про C# вопрос был задан, как я полагаю, потому что все (также как и я кстати) боятся гемора с переходом на C# и повторения истории проекта Green.

Кстати - я же не говорю что я вообще считаю что Аксапта в принципе не туда идет. В 2009ой появилось очень много вполне полезных фич. И судя по тому инсайду который я про 6ку знаю - там еще больше появиться. Просто тема с C# меня напрягает. Надо либо перестать пиариться на тему неготовой технологии, либо ПОДРОБНО обяснить КАК собираются на эту технологию переходить. Чтобы все заранее могли оценить риски и проблемы.

[_scorp_]

У меня присутствует следующее опасение от грядущего перехода с X++ на C# :
В C# существуют более сложные конструкции языка чем в X++ и продвинутые C# - еры начнут ими пользоваться. В итоге, читая код, нужно будет сначала разбираться в конструкциях языка, а потом уже в бизнес-логике. X++ прост и выразителен, читая код, ты сразу понимаешь, что в нем происходит. В общем, на мой взгляд, есть вероятность того, что разработка на С# будет занимать больше времени.

[Lemming]

Цитата:

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

У меня присутствует следующее опасение от грядущего перехода с X++ на C# :
В C# существуют более сложные конструкции языка чем в X++ и продвинутые C# - еры начнут ими пользоваться. В итоге, читая код, нужно будет сначала разбираться в конструкциях языка, а потом уже в бизнес-логике.

Как я понял, с поверхностного ознакомления, C# не настолько сложный язык что бы читая код, каждый раз приходилось в нем разбираться

Цитата:

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

X++ прост и выразителен, читая код, ты сразу понимаешь, что в нем происходит.В общем, на мой взгляд, есть вероятность того, что разработка на С# будет занимать больше времени.

Завидую...читаешь код, например: ЗиК, Налоговых регистров, разноску по ГК, расчет спецификаций, закрытие склада, Обороток в любых модулях(RLedgerSheet*), даже в отладчике, все не так очевидно, что уж там просто исходники. Впрочем, возможно это только у меня Но в целом, это к тому, что в случае Х++ и C# вопрос очевидности языка - дело десятое. И там, и там, можно "намудрить".

p.s. Как красноглазик в данном вопросе , я за систему на едином и современном языке: С#, но только в случае если это действительно грозит снижением скорости разработки исключительно на период погружения в тонкости новой платформы и при сохранении существующего функционала.

[_scorp_]

Цитата:

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

C# не настолько сложный язык что бы читая код

Он не сложный, но возможностей "загнуть" там гораздо больше чем на X++. Вот например что здесь выведется на экран

class X<T>
    {
        public static void PrintTypes()
        {
            Console.WriteLine(typeof(T).FullName);
            Console.WriteLine(typeof(X<X<T>>).FullName);
        }
    }
    class App
    {
        static void Main()
        {
            X<int>.PrintTypes();
        }
    }

Или здесь

class Program
    {
        delegate int DelegateType(int valTypeParam, string refTypeParam,
          ref int refParam, out int outParam);

        static DelegateType GetMethod()
        {
            return delegate(int valTypeParam, string refTypeParam,
              ref int refParam, out int outParam)
            {
                System.Console.WriteLine("Hello valParam:{0} refTypeParam:{1}",
                  valTypeParam, refTypeParam);

                refParam++;
                outParam = 9;
                return valTypeParam;
            }; 
        }

        static void Main()
        {
            DelegateType delegateInstance = GetMethod();
            int refVar = 5;
            int outVar;
            int i = delegateInstance(1, "one", ref refVar, out outVar);
            int j = delegateInstance(2, "two", ref refVar, out outVar);
            System.Console.WriteLine("i:{0} j:{1} refVar:{2} outVar:{3}",
              i, j, refVar, outVar);
        }
    }

[belugin]

Цитата:

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

Он не сложный, но возможностей "загнуть" там гораздо больше чем на X++. Вот например что здесь выведется на экран

            Console.WriteLine(typeof(X<X<T>>).FullName);

я как человек, который знаком с C# слабо, думал, что выведется X<X<int>>, вывелось
X`1[[X`1[[System.Int32, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]
], test, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null]]

Я так понимаю, что тут
1. полные именя типов
2. int32 подвергся боксингу
3. `1 означает "от одного аргумента"

Я прав? То есть проблема в реализации преобразования типа тип к строке?

Цитата:

Или здесь

class Program
    {
        delegate int DelegateType(int valTypeParam, string refTypeParam,
          ref int refParam, out int outParam);

Вот тут я вообще не понял в чем проблема - вроде все работает как надо - как аргументы передаеются так и печатаются.

У меня вывело

Hello valParam:1 refTypeParamne
Hello valParam:2 refTypeParam:two
i:1 j:2 refVar:7 outVar:9

вроде так и должно быть.

[_scorp_]

Цитата:

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

То есть проблема в реализации преобразования типа тип к строке?

Здесь на самом деле нет ни какой проблемы. Для generic-ов FullName выводиться по другому и в MSDN об этом говорится. В этих примерах нет никаких ребусов, я просто хотел сказать, что в X++ нет таких синтаксических конструкций и читать его следовательно легче (по крайней мере для меня).

Цитата:

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

"Любопытство взяло свое", очень жду аналоги методов на Х++

Даже не знаю как это написать на X++. Тут нет ни generic-ов, ни делегатов, ни out параметров, ни значимых типов, которые можно передать по ссылке, да много чего нет... Но я с Вами согласен, что и на X++ можно намудрить, просто здесь для "мудрецов" больше возможностей

[MikeR]

Спасибо, fed. Никто ранее не говорил, что придется деплоить целиком приложение. А как быть с AOS (передергивать) ? Или я чего не понял?