Для начала отлично.
В свое время мы с Dmitro думали над возможными реализациями ООП в 8ке, и пришли почти к такому же решению, однако делать не стали.

Так сразу же вопросы и пожелания и своя толика видения развития.

Сделано ли множественное наследование?
Будет ли какая-то декларативность в описании классов?

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

А вот тут Dmitro (как больший чем я спец по 8ке) подсказывает - у обработки могут быть реквизиты обработки с типом "ОбработкаОбъект.ИмяКакойтоОбработки", которые как-раз и было бы удобно использовать как базовые классы.
Те у ВК допустим метод - CreateClass(ИмяОбработки)
ВК создает эту обработку, базовые классы создаются САМИ как реквизиты этой обработки.
Дальше ВК должна просто обойти реквизиты обработки, выделить среди них те, которые есть базовые классы (может там инфа в синонимах метаданных и тп), и вернуть уже свой объект. Также для каждого подобъекта, являющегося классом, можно будет вызывать какой-то инит-метод, в который передавать ссылку на конечный объект, для реализации виртуальных вызовов (аналог Сам(Контекст) в 1С++).

Вобщем, надо думать над этим, и для начала определиться со стандартами - как прописывать/создавать иерархию наследования, как инициализировать, как описать public/protected/private методы и наследование,  и тп.

Множественное наследование есть. Метод Инит может принимать 16 базовых классов. Если у базовых объектов совпадают методы или свойства, то обращение идет к методу объекта, указанного раньше в цепочке параметров метода Инит.

Декларации класса отдельно от реализации сейчас нет. Тут музыку заказывает платформа V8. Именно в модуле объекта обработки указывается состав приватных и публичных методов и переменных. Можно сделать декларацию, но она будет вторична. Зачем? (Если только для указания количества параметров в методе. Сейчас появляется ошибка, если параметров недостаточно. Если их больше, то ошибка не появляется. Лишние параметры просто игнорируются.)

Что касается реквизитов обработки. Можно и так сделать. Я думал делать переменную модуля, если нужно сохранить ссылку на базовый класс. В нынешнем варианте создание класса выполняется в процедуре _КакКласс. Здесь у разработчика максимум свободы. Класс можно создавать на основе здесь же созданных объектов или реквизитов обработки или чего-то еще. _КакКласс может быть параметризованным, куда при создании класса может быть передан экземпляр документа, справочника или элемента формы. Зачем задавать жесткий алгоритм создания класса только на основе реквизитов обработки с формализованными именами?? В чем смысл?

Robert писал(а) 16. Марта 2009 :: 10:13:

Чтобы превратить то, что ты создал - смесь из: ручное создания кирпичиков + укладка кирпичиков в блоки + итератор по методам кирпичиков - в нормальное ООП.

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

Тут надо все обдумывать. В 8ке я не спец.
Как сказал Dmitro, если реквизит обработки имеет тип ОбработкаОбъект, он создается сам, автоматом.
Как насчет других типов - не знаю, наверное создаются просто пустые (типа как в 7ке - СоздатьОбъект("Документ")
Если нужны установить готовый - передавать в метод CreateObject твоей фабрики, с указанием, для какого базового класса передается.
Например
а = фабрика.Создать("МойКласс", "Документ=", НужныйДок);

реквизиты обработки доступны для записи, те ты в ВК можешь создать объект обработки, и присвоить ее реквизиту переданное значение.
Сами обработки называть именно с префиксом "класс" не нужно. Нужен способ определить, какие из реквизитов создаваемой обработки являются базовыми классами. Как вариант - название такого реквизита должно начинаться с "класс", например реквизит "классБазовый", тип реквизита - Обработка.Объект.БазоваяОбработка. Еще вариант - у любой обработки можно получить метаданные, перебирать в них реквизиты, и то что это класс, определять из допустим синонима метаданных реквизита обработки.

Теперь виртуальность. Допустим декларируем, что реквизит обработки с именем "Контекст" - предопределенный, и в твоей ВК при создании объектов, если у них есть реквизит Контекст, записывать туда ссылку на создаваемый объект:
Например, иерархия Класс2 наследуем от Класс1.
Создается твой COM объект, obj1, для Класс2.
В созданном объекте обработки в реквизит Контекст записывается ссылка на obj1.
Перебирая его базовые классы, находим Класс1, у него тоже есть реквизит Контекст. Туда тоже записываем ссылку на obj1.
Теперь в Класс1 можно написать Контекст.Метод1();
Если Класс2 переопределил Метод1, то вызовется его реализация, иначе реализация из Класс1.
Такой метод прмименяется в 1С++, называется Сам(Контекст).

artbear писал(а) 16. Марта 2009 :: 12:38:


Фишка в том, что для реализации виртуальности, передавать в базовый класс ссылку на класс наследник нужно не тот объект обработки, который создает сама 1С, и счетчиком ссылок которого мы не можем управлять, а ссылку на COM-объект-"обертку", который создает Robert для этого объекта, и счетчик ссылок которого в его полном распоряжении

Но тестить да, нужно!

Вот так в первом приближении.
Ограничения: Классы могут быть только среди обработок конфигурации. Базовый класс не может быть унаследован от третьего класса, т.е. только два уровня иерархии классов.
Реквизиты, определяющие базовые классы, имеют префикс "класс".
Создание экземпляра класса:

ЗагрузитьВнешнююКомпоненту("RClassMngr.dll");
Cls = Новый COMОбъект("RClassMngr.Class");                                    
Cls._CreateObject("Класс1");
Cls.МетодКласса();