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

[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, т.е. полностью отрытые внутри своего пакета.