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

[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

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

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

[_scorp_]

Цитата:

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

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

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