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

    struct MethodCall : public    System::ObjectImpl<    MethodCall2Params<T1, T2, R>, 
                            System::Object<DEFAULT_THREADING> >
    {
        // идентификатор обьекта, который позволяет получить экземпляр обьекта  в адресном пространстве удаленной машины
        ObjectRuntimeId    _ObjId; 
        std_string        _MethodName;
        
        //Блок для регистрации полей в метаклассе
        //
            BindProperty(    "ObjectId", 
                    &MethodCall::_ObjId );
            BindProperty(    "MethodName", 
                    &MethodCall::_MethodName);
        //
        //Блок для регистрации полей в метаклассе
        
        virtual    void    CallMethod() = 0;
    };

    template< typename T1, typename T2, typename R >
    struct    MethodCall2Params : public    System::ObjectImpl<    MethodCall2Params<T1, T2, R>, 
                                MethodCall >
    {
        typedef    typename        MethodCall2Params<T1, T2, R>    MethodCall2ParamsImpl;
        T1 _Param1;
        T2 _Param2;
        R _RetVal;
        //Блок для регистрации полей в метаклассе
            BindProperty(    "P1", 
                    &MethodCall2ParamsImpl::_Param1 );
            и так далее...
        //Блок для регистрации полей в метаклассе
        void    CallMethod()
        {
            TheObject* pObj = GetObjectFromRepository( _ObjId );
            TheClass* pClass = pObj->GetClass();
            typedef    TYPELIST_2(    T1, 
                        T2 )    PARAM_LIST;
            Loki::Functor<R,PARAM_LIST> pFn = pClass->GetMethod< R, PARAM_LIST>(_MethodName);
            _RetVal = pFn( _Param1, _Param2 );
        }
    };

Макросы регистрации метаклассов и прочее. И так, не вдаваясь в подробности транспорта, на клиентской стороне "сериализуется" вызов метода, на серверной стороне вынимается из стрима абстрактный обьект MethodCall* и делается вызов CallMethod. Дальше в том же стиле нужно отправить результат обратно. Таким образом не чувствуется ограничение нашей строготипизированной рефлексии, методы обьектов вызываются привычным для С++ программистов образом, и сохраняется динамичность.
Многие могут найти применение данного подхода в приемах программирования, основанных на дизайне с другими видами контрактов. Время будет тратиться только на получение функторов методов, далее же вызов будет эквивалентен виртуальному вызову, так что в итеративных вызовах полученного ранее прокси на метод разница не чувствуется, можно и вовсе отказаться от базовых классов и перекрытия виртуальных методов, столь привычных С++ программистам, появляется возможность имитировать стиль программирования принятый на Смолтоке, что наложит отпечатки на дизайн и приемы проектирования, при этом нет необходимости заполнять страшные стеки параметров динамических Invoke, свойственные рефлексиям джавоидов.

Еще одна тема, которую мне бы хотелось обсудить, это возможность сохранения дополнительных метаинструкций для рефлексивных полей класса, которые в последствии могут применяться для генерации и разметки визуального интерфейса, представляющего содержимое данного класса. Инными словами дизайн паттерн МВЦ по большому счету большой и бесконечный workaround, хотелось бы писать компоненту и сопровождать ее кодом разметки, по которому конкретный фреймворк мог генерить как миниму визуализацию компоненты и фронтсайт контроллер, компонента же будет выступать в роли бексайт контроллера. Таким образом, WEB framework генерит веб визуализацию компоненты, GUI framework генерит окна и так далее. Хотелось бы обсудить этот вопрос, попытаться формализовать эту идею.