mfp: What's up with this semicolon?

[Blog bot]

Источник: http://blogs.msdn.com/mfp/archive/20...semicolon.aspx
==============
The most visual idiosyncrasy in X++ is the dangling semicolon separating the variable declarations from the actual code. But why is it there and why is it needed?
Best practices in X++ (as in most other modern languages) suggest using TitleCase when declaring (and referring to) types, and using camelCase when declaring variable types. Here is an example of what an X++ developer could write:
AccountNum accountNum;
;
accountNum = "4000";
As X++ (unlike most other modern languages) is case insensitive, this is what the compiler will see:
accountnum accountnum;
;
accountnum = "4000";
Suppose the dangling semicolon wasn't there. Then the "accountnum" statement in the second line is ambigious. It could either refer to the type or to the variable. The X++ compiler assumes it is the type, and thus generates a compilation error when encountering the equal (=) sign; as you cannot assign into a type. By inserting the dangling semicolon you instruct the compiler that there will be no more variable declarations; and thus "accoutnum" is a reference to the variable and not the type.
If it was made a priority to get rid of dangling semicolons, what could be done?

1. X++ could be made case sensitive. This would likely break all customizations and solutions available; unless it is accompanied with a code "beautifier".
2. The compiler could be made more intelligent by looking one more token ahead before giving up. As human beings easily can see through the ambiguity; the compiler should be able to do so too. I guess the developer solving this issue would kudos in AX-land.

The above is a draft of a blog post I wrote last week. I wrote it for two reasons: Mainly to explain the dangling semicolon issue, and secondarily to lay out bait for a developer on the X++ team. As it turned out more progress was made this weekend than the past eleven years in this corner of AX . After writing the draft above I decided to take a look under the covers in the compiler; to gauge the challenge, I guess. So I installed the latest version of VS and downloaded the latest source code for the kernel. (These are some of the freedoms you enjoy when working for Microsoft). After playing around with the grammar for a while, I came to the conclusion that the grammar is crisp and clear; the scanner is just feeding the wrong tokens to the parser. I found the spot where non-keyword tokens are evaluated. I discovered that if a token shares name with an X++ type (Class, Table, EDT, etc.) the parser assumes it is a type-token. After finding this spot it took me less than two hours to write some code that reads one token ahead and only assumes the current token is a type-token when it is followed by another non-keyword token. Sunday afternoon I had build 585 (the Release Candidate (RC0) of AX 2009) with a twist on my box: The dangling semicolon is no longer a requirement. I enjoyed the rest of the day in the sun with my family.
This morning I have created a package with my findings and sent it to the X++ team for evaluation. This change will not make it into AX 2009; but I'm confident those of us writing X++ code at Microsoft will enjoy this very soon. The rest of you will have to wait for AX6.0.


==============
Источник: http://blogs.msdn.com/mfp/archive/20...semicolon.aspx

[mazzy]

Цитата:

Сообщение от Blog bot

1. X++ could be made case sensitive. This would likely break all customizations and solutions available; unless it is accompanied with a code "beautifier".

Ой!
По-моему, точка с запятой меньшее зло

[oip]

Цитата:

Сообщение от Blog bot

This change will not make it into AX 2009; but I'm confident those of us writing X++ code at Microsoft will enjoy this very soon. The rest of you will have to wait for AX6.0.

Дык в коде для всех версий до 6ки им же все равно придется использовать этот семиколон, а то у конечных пользователей компилиться не будет. Так что вроде как они как и мы будут шестерку ждать. Просто они ее раньше гораздо увидят.

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

[somebody]

Лишь бы "висячая" точка с запятой не вызывала ошибки, это действительно удобно (и привычно) для разделения объявлений и кода.

P. S. Более умный компилятор == более медленный??

[belugin]

можно сделать прагму или свойство объекта для нового case-sensitive синтаксиса

Как например в nemerle сделали с синтаксическими отступами.

Тогда можно будет oбъявлять по месту:

for (Int i=1; i<=conLen(theContainer); i++)
{
...
}

[belugin]

>>P. S. Более умный компилятор == более медленный??

Не думаю, что сильно намного

[oip]

Пора начинать акцию "Спасем Semicolon!"?

[belugin]

Я думаю, если так нужен этот костыль, можно изобразить его в виде коммента

[oip]

И попросить всех остальных так делать? Иначе смысла нет. В том-то и прелесть текущей ситуации, что семиколон - почти "обязателен". Я бы официально оформил это как фичу языка X++ и все.

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

[Blog bot]

Источник: http://dynamics-ax.blogspot.com/2008...semicolon.html
==============
Well, if you have done X++ development, and done it for at least over 6 months, at one point in your training or in your X++ development life you have wondered why or why must we use a dangling semicolon to denote the end of our Variable delcarations? And why can't we declare variables throughout the code as needed.

Well for the longest we have just had to put up with it, but over at MFP's Two Cent's blog we have an answer and solution (in DAX 6.0 release) so that come DAX 6.0 we should no longer have to have the dangling ; (semicolon).

Check out the direct link here: What's up with this semicolon?

I know this is not a Major development, but it is for sure note worthy! Check back soon!Find a job at: DynamicsAXJobs.com, also post a job for only $99.00!


==============
Источник: http://dynamics-ax.blogspot.com/2008...semicolon.html

[kashperuk]

Я вот что-то читаю и возмущаюсь.
Неужели это вообще проблема? Неужели объяснение, почему ее необходимо добавлять - такое сложное? Как будто это какое-то скрытое знание, дающееся только единицам

[mazzy]

Если честно, то да.
Тем, кто привык к другим языкам программирования очень трудно объяснить, что имя переменной может совпадать с именем класса.

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

В принципе понятно. Но...

[Михаил Андреев]

М-да.. Нашли серьёзную проблему для исправлений.

2 mazzy:
Насчёт бухгалтера ты прав. Но программеры очень легко нюансы программирования понимают. И такие мелочи, как точка с запятой, совпадение имён типов и переменных, смешные ограничения Query.... достаточно один раз сказать, чтобы больше ошибок не повторялось.
С бухгалтерами часто клиника

[gl00mie]

Цитата:

Сообщение от Blog bot

The most visual idiosyncrasy in X++ is the dangling semicolon separating the variable declarations from the actual code. If it was made a priority to get rid of dangling semicolons, what could be done?

1. X++ could be made case sensitive. This would likely break all customizations and solutions available; unless it is accompanied with a code "beautifier".
2. The compiler could be made more intelligent by looking one more token ahead before giving up. The compiler should be able to do so too. I guess the developer solving this issue would kudos in AX-land.

Уж не этим ли прельстило Понтоппидана решение "сделать компилятор более умным"?
А по мне так лучше было бы сделать X++ регистрозависимым как та же Java, которая вроде как вдохновила некогда праотцов из Дамгаарда.

Цитата:

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

Ой! По-моему, точка с запятой меньшее зло

Это еще почему? С точки зрения поддержки старого кода, косячно-корявого в плане регистрозависимости и соблюдения Best Practices? Дык, натравить на него один раз beautifier, а потом - руки отрубать (образно говоря, т.е. компилить код с ошибками) неряшливым кодерам, пришедшим из бейсика, которым по барабану и Best Practices, и рЕгисТР БУкв
Собственно, Понтоппидан лукавит, говоря об автоматическом "причесывателе" кода как о неком мифическом существе. Смотрим в Best Practices (давнишний, еще от 3-шки), раздел «X++ layout», подраздел «Upper/lower case»:

Цитата:

• System functions are treated like other methods (initial lowercase). Intermediate words may start with uppercase.
• true, false, null are all lowercase.
• Basic types are all lowercase, for example: str, date, int, real, void, boolean.
• Reserved word are all lowercase (for example see the System Documentation>Reserved Words list). Intermediate words may start with uppercase. Example: if, while, for, select, ttsCommit.

Не знаю, как на счет «intermediate words may start with uppercase», но в самом ядре все системные функции и ключевые слова прописаны сугубо в нижнем регистре - любой желающий может в этом убедиться. А теперь смотрим в стандартное приложение DAX4, сравниваем с AX3 и ищем десять различий (в тех местах, где код не менялся из-за введения нового функционала, всяких Code Access Security и проч.): сразу видно, что код "причесали": привели все ключевые слова и системные функции к нижнему регистру, привели упоминания элементов перечислений к тому виду, в каком они представлены в AOT, etc (я уже как-то писал об этом). Т.е. явно видно, что код приложения 4-ки прошерстили неким инструментом, зачатки которого уже давно живут в самом приложении, см. Add-ins\Смена регистра в исходном коде (класс SysSourceNameWash).
Так что в плане перевода Х++ в регистрозависимые языки нужна по большому счету лишь политическая воля - вместо желания "прославиться в AX-сообществе".

Цитата:

Сообщение от Blog bot

This morning I have created a package with my findings and sent it to the X++ team for evaluation. This change will not make it into AX 2009; but I'm confident those of us writing X++ code at Microsoft will enjoy this very soon. The rest of you will have to wait for AX6.0.

И эти люди еще хотят скрестить DAX с VS и .Net'ом...

Цитата:

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

Более умный компилятор == более медленный??

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

Цитата:

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

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

А по мне - лучше бы докрутили среду разработки до уровня VS, где редактор понимает, где тип, а где переменная типа, и подсвечивает их по-разному. Тогда и "костыли" в виде висячей точки с запятой не понадобятся...

[Михаил Андреев]

Цитата:

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

А по мне - лучше бы докрутили среду разработки до уровня VS, где редактор понимает, где тип, а где переменная типа, и подсвечивает их по-разному.

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

[belugin]

Этим своим решением по поводу того, что типы и переменные могут совпадать, авторы X++ закрыли кучу возможностей:

- использование использование типов как значений (вместо tableNum FieldNum - просто названия таблиц)

- объявления по месту первого использования

- использвание имен функций как константы

[mazzy]

Цитата:

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

А по мне - лучше бы докрутили среду разработки до уровня VS, где редактор понимает, где тип, а где переменная типа, и подсвечивает их по-разному. Тогда и "костыли" в виде висячей точки с запятой не понадобятся...[/FONT]

Осторожнее с желаниями - они имеют привычку исполняться
По мне - лучше бы выполнили свои обещания в следующих версиях и перевели среду разработки в VS. Тогда бы и отладчик был бы нормальный.

Цитата:

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

Этим своим решением по поводу того, что типы и переменные могут совпадать, авторы X++ закрыли кучу возможностей:

Не спорю.

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

[gl00mie]

Цитата:

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

Этим своим решением по поводу того, что типы и переменные могут совпадать, авторы X++ закрыли кучу возможностей:
- использование использование типов как значений (вместо tableNum FieldNum - просто названия таблиц)

Функции tablenum()/fieldnum() возвращают значения вполне определенного типа TableId/FieldId, соответственно. Если бы можно было использовать типы как значения, то все равно для возможности параметризации ряда выражений пришлось бы ввести какие-то типы для таблицы и поля, и все опять вернулось бы к использованию неких функций, возвращающих значения таких типов для таблиц и полей.

[gl00mie]

Цитата:

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

По мне - лучше бы выполнили свои обещания в следующих версиях и перевели среду разработки в VS.

«Докрутить среду разработки до уровня VS» не противоречит «перевести среду разработки в VS»

Цитата:

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

Тогда бы и отладчик был бы нормальный.

А чем не устраивает нынешний отладчик? Меня лично - в основном тем, что он в ходе выполнения кода не останавливается на закрывающей скобке метода, так что, к примеру, отлаживать методы из одного оператора return <какое-то выражение> бывает очень неудобно; а еще он мне не нравится тем, что не умеет показывать значение возвращаемого значения (это связано с первой хотелкой), при том что само ядро явным образом поддерживает такую возможность - у класса interpret есть шаблонные (типизированные) методы setReturnVal(), которые дергатся там и тут и устанавливают текущее значение вычисляемого выражения.
Ну еще условные точки останова не поддерживает (но это скорее заморочки того же ядра) да содержимое некоторых контейнерных типов показывает неинформативно. А в остальном - отладчик как отладчик...

PS. К слову, о "нормальных" отладчиках... Недавно в своей программулине на C# боролся с косяком, связанным с маршаллингом параметров вызываемой unsafe-функции. Отладчик VS честно показывал исключение, мол, код обратился к такому-то адресу в памяти, который не может быть прочитан, но разобраться в причине не предоставлял никакой возможности. Пришлось прибегнуть к старому доброму OllyDbg, в котором причина выяснилась за 5 минут.

[mazzy]

Цитата:

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

«Докрутить среду разработки до уровня VS» не противоречит «перевести среду разработки в VS»

Опыт подсказывает, что они "понимают" буквально.
Сказано "докрутить" - будут докручивать, вместо...

Цитата:

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

А чем не устраивает нынешний отладчик?

Нет условных точек останова.
Приходится выкручиваться http://forum.mazzy.ru/index.php?showtopic=1926

Цитата:

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

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

И не только контейнеров.
Экземпляры системных классов никак не показываются.
С длинными строками фиг разберешся.
Постоянно вылетает при просмотре Memo полей.