Для чего нужен я() ?

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

Это как в С++
Можно написать:
ptr->SomeFunc(),
а можно
ptr->SomeClass::SomeFunc()

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

Еще раз объясни.
Как сделать чтобы везде было написано одно и то же: Сам(Контекст),
но чтобы в одних местах конфигурации все работало по старому, а в других - по новому?
Писать в заголовке вместо "класс" "правильныйкласс" что ли?
Как быть когда в иерархии надо смешать "правильные" и "неправильные" классы?

Допустим, я решил потихоньку переходить на "правильные классы".
Как мне быстро определить, не глядя в реализацию, что вот этот класс я могу
объявить как "правильный" и не нарушу никак его работу?

Как много было вопросов от пользователей, связанных с тонкостями реализации ООП, за последний год на итлэнде?

Цитата:

Хм. Да уж.

Да, именно декларатором типа "класс правильный Документ_РКО {}".
Если смешать правильные и неправильные, тогда при вызове из правильного будет использоваться CProxyClass, а при вызове из обычного - CComponentClass. Это потенциальный источник проблем, но позволит переводить классы в рабочем порядке.
Честно говорю, полностью список проблем еще не обдумывал - поэтому есть предложение применять декларатор ко всей конкретной иерархии сразу.

Цитата:

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

Т.е. сделать нормальный рефакторинг класса, и все.
Либо не переводить старые классы, а начинать переводить с новых.

И юнит-тестирование должно помочь. Но тут меня совсем щас в утописты запишут.

То есть из-за твоей любви к "чистым" принципам ООП я должен буду перелопачивать весь свой старый код?

Теперь представь, сколько работы надо будет переделать, чтобы реализовать работу "правильных" классов. Доделывать разбор заголовков классов, процедуру создания КОПов, да много чего еще. А вот вирт() и я() я сегодня добавил в ветку в репозитарии, изменив пяток строк в componentclass.cpp

[quote author=orefkov link=1149237614/60#67 date=1149323836]То есть из-за твоей любви к "чистым" принципам ООП я должен буду перелопачивать весь свой старый код?
[/quote]
Нет, конечно, не должен. Можешь перелопачивать, можешь - нет. Разве это не свобода выбора?

[quote]
Теперь представь, сколько работы надо будет переделать, чтобы реализовать работу "правильных" классов. Доделывать разбор заголовков классов, процедуру создания КОПов, да много чего еще. А вот вирт() и я() я сегодня добавил в ветку в репозитарии, изменив пяток строк в componentclass.cpp[/quote]
Да ладно тебе, нам же сроки никто не ставит. Ну, буду разбираться потихоньку.

И потом, декларатор отмены кеширования все равно надо делать.
И падение в CComponentClass:
[quote]
[I] EXH: Handled exception in CComponentClass::DecrRef(void) {1 occurrence}
Exception address: [KERNEL32.dll ip=0x67E41ACE]
Handler: CComponentClass::DecrRef(void) [ComponentClass.cpp:950]
}
catch(...) // artbear
{
=> }[/quote]
Все равно надо переделывать.

Так что работы-то и без этого хватает. Поскольку все в одном месте, можно и заняться.

Функция вирт() - это хорошо. Давно надо было такую ввести. Только как к ней отнесется синтакс-контроль конфигуратора? Правда лучше было бы ноазвать ее Сам(). А еще лучше было бы сделать предопределенную переменную Сам.

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

orefkov писал(а) 05. Июня 2006 :: 04:51:


А разве нельзя в модуле переопределить функцию?

Кстати, многие уже пользуются таким вариантом:

Функция Конт(Конт) Возврат Конт; КонецФункции
Функция Сам() Возврат Конт(Контекст); КонецФункции 

Цитата:


Не переменной, а свойством. Типа

Функция Get_Сам()
    Возврат Сам();
КонецФункции