kms писал(а) 02. Июня 2006 :: 12:02:

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

Мое предложение вот в чем: давайте дадим разработчику приложения свободу выбора. Захочет - воспользуется старым механизмом поиска метода в иерархии (вызвав метод через Сам(Контекст)). Захочет - воспользуется твоим новым поиском с помощью некоторого нового метода Сам(Контекст).ПолучитьТекущуюВеткуИерархии().

kms писал(а) 02. Июня 2006 :: 12:07:


Эта. Не рви мне шаблон, пожалуйста. И седмину тоже
Сегодня моя очередь оффтопить в твоей ветке.

fez писал(а) 02. Июня 2006 :: 12:11:

Черт рыжий. Ладно, оффтопь.

Отвечу обоим сразу.

Конечно, я вижу проблему обратной совместимости. Механизм контроля предлагаю включать по запросу.
Цитата:

Ну нельзя этого делать, пойми, пожалуйста. Нельзя.
Если тебе нужны конкретные данные из подкласса - пользуйся полиморфными функциями.
Определяй интерфейс в супере и получай данные из переопределенного метода подкласса.
Это будет правильно.
Нужны тебе данные документа - вызови метод подкласса - наследника РКО, заполни тз и верни ее в суперкласс.
И делай с ними, что хочешь. И это будет правильно.

Цитата:

Не будут.

sedmin писал(а) 02. Июня 2006 :: 12:15:


Цитата:


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

Родители, кстати, (объекты суперклассов, ты это имел в виду?), у обрезанного и необрезанного общие будут.
Т.е. заменив в одном месте, заменишь и в другом. Это же один объект, независимо от преобразований.

sedmin писал(а) 02. Июня 2006 :: 12:28:

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

Находим метод - здесь ничего не мешает, он в пределах ветки Первого Родителя.

Запускаем Метод_ПервогоРодителя(), при это поиск выполняется во всем дереве, т.к. контекст исполнения перешел в подкласс.

Выполняем Метод_ПервогоРодителя(), при этом внутри метода поиск (если он есть) идет в пределах ветки Первого Родителя

Запускаем Метод_ВторогоРодителя(), при это поиск выполняется во всем дереве, т.к. контекст исполнения перешел в подкласс.

Выполняем Метод_ВторогоРодителя(), при этом внутри метода поиск (если он есть) идет в пределах ветки Второго Родителя

Как видишь, никаких проблем нет. Отличий нет.
Добавлена изоляция суперклассов, но схема предельно проста и надежна.

Выглядит заманчиво. Но чувствую, что где-то лежат грабли.

Продублирую, а то если кто с конца читает ветки, так им неудобно в начало смотреть:

orefkov писал(а) 02. Июня 2006 :: 09:45:


Цитата:


А эти проблемы - проще не придумаешь. Решения:

1. поиск методов вести только среди виртуальных, определенных в текущем контексте исполнения (с учетом интерфейсов суперклассов) - т.е. только в пределах интерфейса текущего контекста.
2. поиск свойств вести только от текущего контекста исполнения вниз.