Вот код на С++:
Цитата:

Печатает, понятное дело, "child", "child".

Всего лишь одно отличие:
Метод meth() чисто виртуальный. А класс base - чисто абстрактный класс.
Соответственно, контроль ошибок - реальный, а не призрачный.

С++ эталон? Не знаю. Но то, что ты написал на питоне - это ужасно.
Впрочем, если тебе не важна правда и ты хочешь остаться при своих - пожалуйста.

P.S.
Код, который ты продемонстрировал - крайне небезопасный. Более того, в 1С ты это можешь отследить исключительно на этапе выполнения.
Я такой код не поддерживаю и поддерживать кого-либо (даже тебя!) в его использовании не собираюсь.

И, напоследок, загляни вот сюда: http://skipy.dev.juga.ru/philosophy/inheritance.html
Не ты ли эту ссылку давал? Или это Палыч был?

Отлично написано, лучше не скажешь.
Прочитай про наследование реализации и наследование интерфейсов, как это сделано в java (в С++ так же).
Если ты поймешь, почему так сделано, у тебя не останется вопросов в отношении того, как должна работать замена базовых объектов в 1cpp.
И почему метод (Проведен()?) или свойство (Фирма?) наследника, которые видны в базовом классе без явного определения интерфейса - это плохо.

Очень, очень плохо.

P.S.
И твоя ошибка в том, что ты путаешь наследование реализации (а в 1С/1cpp это именно так) с наследованием интерфейсов.
При этом не имея никакого желания интерфейс этот определять и забивая болт на понятие инкапсуляции вообще.

DrACe писал(а) 31. Мая 2006 :: 03:26:

Да уж. Тема вызвала прилив сил

В отношении ЗаменитьЭксзБазовогоКласса().

Это не виртуальная функция. Да, она определена для каждого класса.
Но это не виртуальная функция. Это, если хочешь, служебная функция.
Она нужна исключительно для конструирования иерархии в 1С.

Ее поведение должно быть детерминировано и здесь я против какого бы то ни было полиморфизма.

Я уже объяснял почему.
Если ты переопределил любую функцию в подклассе, проблемы не будет.
Ну возвращал у тебя Вид() "Круг", стал возвращать "Квадрат" какие проблемы?
"Переопределение" же ЗаменитьЗксзБазовогоКласса в корне изменит поведение суперкласса, если тот полагается на определенную работу ЗаменитьЭксзБазовогоКласса().

И я понимаю твое желание ее переопределить, поскольку фактически у тебя класс является чисто абстрактным (просто ты не сразу в этом признался).
Для чисто абстрактного класса переопределить ЗаменитьЭксзБазовогоКласса() было бы возможно.
Одна проблема: у нас нет поддержки абстрактных классов в 1С/1CPP.
Значит, обязательно найдется кто-то, кто возьмет твою иерархию, не разобравшись, где классы абстрактные, где нет, инстанциирует объекты абстрактных классов и получит труднонаходимые, но конкретные грабли.

Короче, без поддержки абстрактных классов, я конкретно против виртуализации ЗаменитьЭксзБазовогоКласса().
А вот не сделать ли поддержку абстрактных классов - это вопрос, над которым нужно подумать.

Здесь я вижу одну проблему: контроль ошибок на этапе компиляции будет невозможен.
Т.е. мы добавим себе работы по контролю обязательного определения чисто виртуальных методов на этапе выполнения.

kms писал(а) 31. Мая 2006 :: 09:43:


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

В целом я согласен с вынесенным вердиктом.

Но все же остается пара моментов:

1. Что будет возвращать ТипЗначенияСтр(Сам(Контекст)), если ее написать в модуле Документы_СБухИтогами?
Если "Документ_РКО", то почему вызов Сам(Контекст).ЗаменитьБазовыйОбъект(НовыйОбъект) работает не так, как ожидалось?

2. Относительно виртуальных методов. Надо признать, что в скриптовых языках, таких, например, как Питон, все методы являются виртуальными. Это только с строгих языках, таких как С++ и Ява введены механизмы, которые позволят отслеживать подобные вещи. Язык 1С и 1С++ (не надо лукавить) надо отнести к нестрогим скриптовым языкам.
И надо оставить в отношении виртуальных методов все как есть, и не считать их появление и использование багом.

В чем тогда разница в результате вызова Сам(Контекст) в модулях Документы_СБухИтогами и Документ_РКО?

sedmin
Тут у меня мнение совпадает с мнением Артура (зачеркнутым).

Здесь, правда, возможны варианты.
Если рассматривать концепцию абстрактных классов, то я не против рассмотрения ТипЗначенияСтр() и ЗаменитьБазовыйОбъект() как чисто виртуальных и, соответственно, возможности их переопределения.

Для классов, которые могут быть инстанциированы (а у нас сейчас все такие), служебные функции не должны иметь возможность переопределения, потому что это приведет к различному поведению суперкласса в случае, когда он создан сам по себе и когда он создан в составе иерархии.

Здесь надо продумать реализацию RTTI, возможно как раз ТипЗначенияСтр() мы и будем использовать как основу RTTI - тогда это также особый случай, который никак не влияет на наше решение по остальным служебным функциям.

Цитата:

До появления 1CPP 1С был чисто объектным и братья Нуралиевы на семинарах задавали сакраментальные вопросы типа "ну, давайте, расскажите нам, что такое ООП и зачем оно вам нужно".
Сейчас мы имеем первичную реализации логики ООП, которая имеет определенные нарушения принципов ООП.
Другое дело, что мы привыкли к этой логике и готовы ее защищать. Потому что это удобно.
В этом есть здравый смысл. Вообще, по концепции ООП и эффективности ее конкретной реализации можно ведь говорить долго.
Меня, если честно, до сих пор поражает список литературы, приведенный Бучем в его книге. Там примерно 50 листов.

Однако дело не в механизмах, которые введены в С++ (С++, кстати, гибок именно за счет позднего связывания), а в нашем решении.
Мы можем сделать проще (хоть вообще все классы в один контекст объединим с произвольным доступом к методам и свойствам).
Мы можем приблизиться к классической схеме ООП и механизмы контроля мы можем обеспечить не хуже, чем в С++.
Правда, только на этапе выполнения.

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