Обсуждение Рефлексии

Привет.

Я так понял это последний вариант:

DEF_CLASS0(a)
public:
    // Methods
    void f()
    {
        i = 1;
    }

    // Variables
    int i;

    // Static Methods
    static void sf()
    {
        si = 1;
    }

    // Static Variables
    static int si;

    // Methods
    DECL_METHODS0(void (this_type::*)())   

    // Variables
    DECL_VARIABLES0(int this_type::*)

    // Static Methods
    DECL_STATIC_METHODS0(void (*)())

    // Static Variables
    DECL_STATIC_VARIABLES0(int*)
};

int a::si;

DEF_METHODS0(a, f)
DEF_VARIABLES0(a, i)
DEF_STATIC_METHODS0(a, sf)
DEF_STATIC_VARIABLES0(a, si)

Что не очень нравится в таком варианте имхо:
1. Интрузивность для описываемого класса. По разным причинам это может быть невозможно. Вплоть до того, что класс описан в хидере сторонней библиотеки.
2. Необходимость дублировать макросы с описанием члена 2 раза - внутри класса и вне класса.
3. Необходимость дублировать 2 раза описывать объявления всех членов - вначале просто как членов класса, второй раз внутри макросов.

Как я предлагаю:

Вначале описывается сам класс как есть:
class a
public:
    // Methods
    void f()
    {
        i = 1;
    }

    // Variables
    int i;

    // Static Methods
    static void sf()
    {
        si = 1;
    }

    // Static Variables
    static int si;
};

Потом отдельно описание класса:

#define CLASS_A(a,
  (void(), f), // methods
  (int, i), // variables
  (void(), sf), // static methods
  (int, si) // static var
)

Далее с помощью вспомогательных макросов из библиотеки можно сгенерировать нужные вещи:

MAKE_RT_REFLECTION(CLASS_A) // Этот макрос генерит функции/класс, необходимые для ран-тайм рефлексии

MAKE_СT_REFLECTION(CLASS_A) // Этот макрос генерит функции/класс, необходимые для компайл-тайм рефлексии

MAKE_SERIALIZATION(CLASS_A) // Этот макрос генерит функции для сериализации/десериализации

MAKE_SERIALIZATION_XML(CLASS_A) // Этот макрос генерит функции для XML сериализации/десериализации

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

Далее нужно сделать макрос, который будет генерить само описание класс, т.е.

MAKE_CLASS_DEF(CLASS_A)

Раскрывается в:

struct a
{
    void f();
    int i;
    static void sf();
    static int si;
};

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

#define CLASS_PERSON(person,
  (), // methods
  (int, id)(int, age)(string, name), // variables
  (), // static methods
  () // static var
)

И далее генерируется описание класса и нужные функциональности:

MAKE_CLASS_DEF(CLASS_PERSON)
MAKE_SERIALIZATION(CLASS_PERSON)

Единственное, что придётся наверное сделать - в класс добавлять некий макрос, если пользователь хочет, что бы библиотека могла получать доступ к приватным членам класса:

class a
private: // <-------------------------
    int i;
   
    CPP_OBJECT_ACCESS(); // Тут в класс должен добавляться некий хук, через который библиотека сможет получать доступ к членам... ну или просто класс библиотеки объявляться френдом
};

По поводу собственно рефлесии.
Я считаю, что нужно вынести функции доступа из класс в свободные функции. Т.к., во-первых, зачем их добавлять в класс? только могут быть конфликты с именами, которые уже есть в классе. Во-вторых, опять же проблема с интрузивностью.

Т.е. не так:

t.*get_method<T, 0>::value)();

А как-то так:

get_method<0>(t)();

Должно быть:
Для ран-тайм рефлексии: доступ по имени/номеру
Для компайл-тайм: доступ по тэгу/номеру
Для препроцессинг тайм рефлекии - наверное надо сделать некие вспомогательные макросы типа: FOREACH_VAR(body), FOREACH_FUNC(body), GET_VAR_NAME(n), GET_FUNC_NAME(n) и т.д.
И для всех вариантов - кол-во членов.

Вобщем я как-то так себе это всё вижу...

Ну и я думаю, надо бы, конечно, в первую голову поглядеть другие аналогичные библиотеки. Поглядеть что и как там сделано. Вот на пример та на мейлинг-листе boost'а, которую я присылал. Наверное ещё есть аналогичные.
Вот, например, ещё библиотека eao197:
http://eao197.narod.ru/objessty/index.htm
Ну она правда очень тяжёлая.

Надо, наверное, сделать какую-то proof-of-concept версию, что бы было от чего плясать и на чём более конкретные детали обсуждать.

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

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

struct status_tag_t
{
  string name;
  int code;
  bool some_flag;

  status_tag_t(char const* name, int code, bool some_flag);
};

DEFINITION(status, status_tag_t // указываем, тэг какого типа мы будем связывать
  (status_one, ("Status One", 100, true))
  (status_two, ("Status Two", 200, true))
  (status_three, ("Status Three", 300, false))
)

И далее в ран-тайм можно получать доступ к этим тэгам:

void f(status s)
{
  if (s.get_tag().some_flag)
    ...
  AfxMessageBox("message status " + s.get_tag().name);
}

Я делал это для enum'ов, но я думаю для членов класса тоже можно. Например что бы с сущностями программы связать читаемые имена и далее можно сделать автоматическкую генерацию диалогов для отображения/редактирования сущностей.

Соотв. в компайл-тайм можно связывать такое:

template<bool f, int i> struct tag_t
{
    static bool const ff = f;
    static int const ii = i;
};

DEFINITION(person
  (age, tag_t<true, 1>) // указываем просто тип, который хотим связать
  (name, tag_t<true, 2>) // указываем просто тип, который хотим связать
  (second_name, tag_t<false, 3>) // указываем просто тип, который хотим связать
)