X++: Is the X++ Compiler Too Flexible?

[Blog bot]

Источник: http://blogs.msdn.com/x/archive/2009...ible-font.aspx
==============

In Microsoft Dynamics AX 2009, the X++ compiler is sometimes too flexible in its rules for code. It is likely at some of these flexibilities will be eliminated in future releases.

This blog entry describes some flexibilities of the X++ compiler that we recommend you not utilize.





[1] Sequence of Default Parameters



Recommendation: In a method declaration, declare parameters that have default values after the last parameter that has no default.



The X++ compiler and runtime currently allows you to disregard this recommendation, as the following code example demonstrates.





class MyClass

{

static public int AddTwoNumbers

(int _firstNum = 4

,int _secondNum)

{

return (_firstNum + _secondNum);

}

}





The following job calls the above AddTwoNumbers method. Notice there is no way to accept the default value of the _firstNum parameter.





static void Job1(Args _args)

{

int iAnswer;

iAnswer = MyClass::AddTwoNumbers(8 ,16);

print( IAnswer );

pause;

}







[2] Access Modifier on Methods



Recommendation: Each time you create a new method on a class, explicitly add an access modifier to the method declaration, meaning public, protected, or private.

If no access modifier is given, the default behavior is public.







[3] No Access Modifier on Classes



Recommendation: Do not add an access modifier to any class declaration.

The X++ compiler ignores the keywords public and protected and private on classes, so adding an access modifier can only confuse other programmers. In effect, all X++ classes are public.







[4] Put TODO First



Recommendation: The TODO should be the first non-whitespace after the start of the comment.



When the X++ compiler detects the string TODO in a comment, it lists a task on the Tasks tab of the compiler output window. The compiler goes a little too far in trying to detect a TODO. For instance, the TODO is detected in each of these two examples:





// Remember TODO Remove the diagnostic prints.





/* Important TODO:

Rewrite this SQL as a more efficient set operation.

*/





The two above examples would be fine if the first words were removed: it would be better to remove the first words Remember and Important.





Источник: http://blogs.msdn.com/x/archive/2009...ible-font.aspx

[kashperuk]

болты затягивают, видимо

[gl00mie]

ну как сказать...

• параметры со значениями по умолчанию, идущие раньше параметров без значений по умолчанию, - это на самом деле какое-то извращение, и то, что компилятор такое позволяет, это никакая не гибкость, а скорее какая-то багофича, причем ближе к багу;
• модификатор доступа public по умолчанию для методов - это просто особенность такая в Х++, связанная с тем, что методы (на формах, в классах, отчетах или, тем более, на таблицах) пишут в первую очередь для использования "извне". просто так удобнее, и это удобство компенсирует нарушение единообразия с другими ОО-языками (С++, C#), где по умолчанию методы получаются private;
• игнорирование модификаторов доступа для классов опять же связанно с особенностями Х++, точнее, с тем, что в приложении нет отдельных каких-то... библиотек, сборок, пространств имен - есть один АОТ, и в рамках него разграничивать доступ к отдельным классам как-то... ни к чему. Зачастую даже с непродуманными модификаторами доступа к отдельным методам классов бывает много мороки: вот объявили в каком-нить COMExcelDocument_RU кучу полезных методов как private, и приходится с этим мучиться, а если еще к целым классам можно было доступ закрывать, то это вообще был бы финиш
• обработка TODO - это вообще косметика. я, если честно, был в полной уверенности, что строки TODO вылавливают проверки BP, а не непосредственно компилятор; ну смотрит он дальше, чем предполагается, - и фиг бы с ним, а перестанет так себя вести - тоже невелика потеря, главное, чтоб работало, как в документации написано

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

[cerbo]

Главное в ООП это инкапсуляция, которая нужна прежде всего человеку, а не компилятору. А такое поведение (паблик поумолчанию) подстрекает к ее нарушению.

Цитата:

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

• модификатор доступа public по умолчанию для методов - это просто особенность такая в Х++, связанная с тем, что методы (на формах, в классах, отчетах или, тем более, на таблицах) пишут в первую очередь для использования "извне". просто так удобнее, и это удобство компенсирует нарушение единообразия с другими ОО-языками (С++, C#), где по умолчанию методы получаются private;

это как раз таки баг из-за непонимания разработчиков что они делают

Цитата:

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

• игнорирование модификаторов доступа для классов опять же связанно с особенностями Х++, точнее, с тем, что в приложении нет отдельных каких-то... библиотек, сборок, пространств имен - есть один АОТ, и в рамках него разграничивать доступ к отдельным классам как-то... ни к чему. Зачастую даже с непродуманными модификаторами доступа к отдельным методам классов бывает много мороки: вот объявили в каком-нить COMExcelDocument_RU кучу полезных методов как private, и приходится с этим мучиться, а если еще к целым классам можно было доступ закрывать, то это вообще был бы финиш

Ты хоть сам понимаешь какую ахинею несешь!!! То что "есть один АОТ" (иными словами одна большая помойка), как раз и есть главная болезнь ахапты.

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

[gl00mie]

Цитата:

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

Главное в ООП это инкапсуляция

А как же полиморфизм с наследованием - они второстепенны?

Цитата:

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

которая нужна прежде всего человеку, а не компилятору. А такое поведение (паблик поумолчанию) подстрекает к ее нарушению.

Еще можно утверждать, что наличие класса Object подстрекает к нарушению строгой типизации при использовании ссылочных типов. Просто надо думать, что делаешь, никто же не мешает указывать модификаторы protected/private для методов классов и private - для тех же методов форм и таблиц.

Цитата:

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

это как раз таки баг из-за непонимания разработчиков что они делают

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

Цитата:

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

Ты хоть сам понимаешь какую ахинею несешь!!!

Полегче на поворотах

Цитата:

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

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

Одна база с несколькими тысячами таблиц, одно приложение и, соотв., один AOT в случае Аксапты - это то, что отличает ERP-системы от набора разрозненных систем, используемых для автоматизации отдельных участков учета. У такого подхода, конечно, есть и свои минусы, но, как говорится, за все надо платить.

Цитата:

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

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

Если предполагается изменение в тех местах системы, которые очень широко используются, то, разумеется, приходится долго и нудно проверять, что при этом может "сломаться"; очень сильно такие проверки облегчаются за счет перекрестных ссылок. Но, опять же, возможность изменением одного места в системе повлиять на работу кучи других участков системы дает просто огромные преимущества, и если они не компенсируют указанные "трудности поддержки", то не рискуйте - пишите свои доработки "сбоку". И в любом случае, написание нормального кода, без "зашитых" ограничений и необоснованных предположений, с соблюдением Best Practices, во многом обеспечивает уверенность в том, что ваш код не "сломается" из-за чиьх-то правок в совершенно неожиданных местах системы.

Цитата:

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

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

Ну если дело лишь в модификаторах доступа, то все в ваших руках: указывая те или иные модификаторы доступа к тем же методам класса, вы задаете для пользователей (т.е. тех, кто будет использовать класс) протокол взаимодействия с вашим классом. Если вы считаете, что в рамках этого протокола пользователи могут в произвольный момент времени вызывать тот или иной метод, оставляйте его общедоступным (public), в противном случае - это ваша, а не компилятора или разработчиков языка, прямая обязанность ограничить доступ к тому или иному методу класса за счет модификаторов protected/private. Аналогично, в Х++ в любом классе-наследнике может быть перекрыт любой не статический protected/public-метод родительского класса, если в родительском классе это явно не запрещено, т.е. фактически все методы являются виртуальными, в то время как в других языках (тех же C++/C#) нужно явно объявлять методы как виртуальные, иначе в производных классах их перекрыть нельзя. Ну и что теперь? Это тоже "баг" в Х++?..

[cerbo]

"А как же полиморфизм с наследованием - они второстепенны?"
Конечно!!! Обратите внимание, что понятия и полиморфизма и наследования определяются через понятие объекта (капсулу). Следовательно, инкапсуляция первична, а полиморфизм и наследование ее дополняют!!!

"Баг - это в моем понимании поведение объекта/системы, отличное от декларируемого при соблюдении "правил пользования" объектом/системой "
"Ну и что теперь? Это тоже "баг" в Х++?"
Да баг, нам ведь "декларируют" что тут ООП со всех щелей так и лезет.

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

Часто разработчик, принимая решение, руководствуется не соглашениями всякими, а правилом "быстрее- лучше". И над каждым проверяющего не поставишь- "Сделал? Работает? Молодец.". Да и зачем платить зарплату, если не доверяешь?

[lev]

Цитата:

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

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

Часто разработчик, принимая решение, руководствуется не соглашениями всякими, а правилом "быстрее- лучше". И над каждым проверяющего не поставишь- "Сделал? Работает? Молодец.". Да и зачем платить зарплату, если не доверяешь?

Не любите кошек? Вы просто не умеете их готовить! (С)

[Maxim Gorbunov]

Цитата:

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

Да баг, нам ведь "декларируют" что тут ООП со всех щелей так и лезет.

Во-первых, а кто это "декларирует"? И какими словами? Цитаты приветствуются

Во-вторых, каким концепциям ООП противоречит подобная реализация виртуальных методов?

В-третьих, если это баг X++, то является ли это багом Java?

[_scorp_]

Цитата:

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

Главное в ООП это инкапсуляция, которая нужна прежде всего человеку, а не компилятору. А такое поведение (паблик поумолчанию) подстрекает к ее нарушению.

Что-то я не понял, что тут нарушается? Инкапсуляция - это сокрытие реализации. Другими словами объект должен предоставлять интерфейс (public методы). При этом другие объекты не должны ничего знать о том, как эти методы реализуются. В X++ все так и есть. Я бы даже сказал, что X++, наоборот, принуждает к инкапсуляции, т.к. даже если захочешь, то не сделаешь члены класса public. Связь с другими объектами только через методы. Объясните поподробнее, что Вас не устраивает.

[_scorp_]

Цитата:

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

Паблик и виртуал по умолчанию- вот настоящий финиш.

В чем финишь? Как здесь уже говорили, а как же Java? И там "финиш" ? Там все методы по умолчанию виртуальные и имеют модификатор доступа Default, т.е. полностью отрытые внутри своего пакета.

[nano3]

Цитата:

модификатор доступа Default

маленькая поправка - не Default, а package (вроде бы)

[_scorp_]

Цитата:

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

маленькая поправка - не Default, а package (вроде бы)

Ну это кто как этот модификатор доступа называет Кто-то просто "по умолчанию" или default, кто-то "пакетный" или package. Писать то его не нужно

[cerbo]

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

На сладкое задачки для слишком умных. Опровергните следующие утверждения:

1. Ахапта это сложная система. То есть такая система, что один человек не может осознать ее устройство за конечный промежуток времени.
2. Никакие соглашения не победят человеческие ошибки (лень).
3. Эффективным способом организации сложных систем является принцип "Разделяй и влавствуй".
4. Java не идеал ООП языка.

З.Ы. А вообще мне некогда с вами тут бадаться, я совсем не троль как вы вероятно подумали.

[Weez]

Т.к. код Аксапты в большей степени доступен для изменения - у cerbo есть отличный шанс переписать его согласено своему видению идеальной системы. А вообще очень порадовали его утверждения, которые на мой взгляд вообще "ниачем ", применительно к предмету разговора (Аксапте). Нафига кому-то тут опровергать что Java не идеал (это на мой взгляд вообще очень субъективно), или то что Аксапта сложная система (а что, есть простая и мощная ERP?)..

[mazzy]

Цитата:

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

На сладкое задачки для слишком умных. Опровергните следующие утверждения:

1. Ахапта это сложная система. То есть такая система, что один человек не может осознать ее устройство за конечный промежуток времени.
2. Никакие соглашения не победят человеческие ошибки (лень).
3. Эффективным способом организации сложных систем является принцип "Разделяй и влавствуй".

Все правильно вы говорите.
Только забываете об одном - о совместимости.

История Аксапты насчитывает уже лет 15.
Модификаторы privet, protected, public появились относительно недавно - лет 5 назад. в ax2.5 из ввели как ключевые слова, но не задействовали. В ax3.0 они стали действовать. Сейчас прошло всего два поколения (ax4, ax2009).

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

Поэтому ответ: пока в полной мере не задействовано. Однако движение в правильном направлении присутствует. Ждем следующих версий.

[cerbo]

Извините, если кого обидел. Просто эмоции.

[Maxim Gorbunov]

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

[Maxim Gorbunov]

Цитата:

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

1. Ахапта это сложная система. То есть такая система, что один человек не может осознать ее устройство за конечный промежуток времени.

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

Цитата:

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

2. Никакие соглашения не победят человеческие ошибки (лень).

А то, что нельзя победить, лучше всего возглавить

Цитата:

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

3. Эффективным способом организации сложных систем является принцип "Разделяй и влавствуй".

Опять же, не ясно, что в данном случае является критерием эффективности. Возьмите для сравнения, например, SAP. Там все организовано так, как вам нравится: пользователь может программировать только с использованием интерфейсов, которые предоставил вендор. С одной стороны, установка обновлений от вендора заметно легче. С другой стороны, стоимость клиентской разработки значительно выше.

Цитата:

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

4. Java не идеал ООП языка.

Ну, идеальный ООП язык применим, скорее всего, только в академической среде. Мы же с вами о промышленной эксплуатации говорим прежде всего