sedmin
Я ж тебе сказал, что детали реализации мне нужно смотреть.
Если тебе ответ нужен сейчас - это действительно не ко мне вопрос, а к Deb'у.

Что касается вопроса как оно должно быть - то я ответил раньше.
Через Сам(Контекст) суперкласса не должно быть возможности обратиться к методам и свойствам других суперклассов (по отношению к общему подклассу), к невиртуальным методам и свойствам подкласса.

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

Палыч писал(а) 31. Мая 2006 :: 17:34:

Это очень, очень интересная история.

fez писал(а) 31. Мая 2006 :: 19:14:

Угу. Расскажи, а?

fez писал(а) 31. Мая 2006 :: 19:09:

По идее, метод ЗаменитьБазовыйОбъект() как "плохой" не должен быть экспортным (и соответственно, виртуальным). Но тогда к нему нельзя будет обратиться из модуля, так как доступен он только через Сам(Контекст).

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

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

sedmin писал(а) 31. Мая 2006 :: 19:28:

А ты почему считаешь, что это "плохой" метод. Чем плох с твоей точки зрения?

fez
Не читал FAQ. Ну зачем читать FAQ, когда есть 3 подсказки: звонок другу (Артур), помощь зала (форум) и 100/0 (код).
Чукча не читатель, чукча писатель.

Точно не прощу. Мы уже вовсю используем экспортные методы как виртуальные, и альтернативы этому я не вижу.

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

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

2. В нормальном языке почему такого метода нет? Потому что там делается
СоздатьОбъект("Наследник").Заполнить(ИдЗаписиБД). Так как в 1С есть две разновидности объектов - те, что создаются через СоздатьОбъект(), и те, которые берутся из ниоткуда (или из фабрики объектов, которая не хочет делать объекты класса "Наследник"), то нужен способ получения наследника из уже готового объекта класса "Родитель".

Для первых объектов годится обычная модель заполнения объектов, а для вторых придумали метод ЗаменитьБазовыйОбъект().

И тут нас ждут грабли: при попытке написать Наследник.ЗаменитьБазовыйОбъект(объект.ТекущийЭлемент()) мы получаем ошибку: "можно использовать только объект, созданный через СоздатьОбъект(), или ГрупповойКонтекст".

Зачем использовать для задания наследования объект, созданный через СоздатьОбъект() непонятно. Можно было сразу сделать СоздатьОбъект("Наследник") и делать с ним все, что угодно.
ТекущиеЭлементы() и ТекущиеДокументы() тоже нельзя использовать.
Построение произвольной иерархии с изменением наследования классов тоже не так давно отключили.

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

Кстати, не знаю как сейчас, а раньше можно было создать наследника для таблиц и списков, которые лежат на форме.

fez
Федор, я еще раз подумал. Я поддерживаю твой вариант.
ЗаменитьБазовыйОбъект() должен являться виртуальной функцией, определенной во всех классах.
И, соответственно, должен работать со всей иерархией.

Напомните мне, пожалуйста
Мы уже рассматривали идею динамического конструирования иерархии классов на этапе выполнения?
Дело в том, что у нас нет классов, как таковых. Мы имеем дело с наборами контекстов с логикой замещения методов.
Ну и почему тогда не конструировать объекты налету?

Типа
Цитата:


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

Давайте, критикуйте.