Re: [Subhandler-devel] Some ideas for architecture

[Laurent P. <lau...@sk...>]

> > What is a Subhandler_Object ? What kind of methods and/or properties will
> > it hold ?
>
> It contains mostly artifacts of the class-system implementation. Each

So basically you're reimplementing GObject from the glib ?

> object instance contains a pointer to a class descriptor (actually it is
> a singleton, just one instance per class) that contains internal data
> (name of the class, a pointer to the superior class descriptor), maybe
> class or static properties  and pointers to all methods, both class
> methods and instance methods.

Why do we need to store pointers to the class and instance methods in the 
class object instance ? Can't we call the methods explicitely like in 
glib/gtk+ ? Only pointers to the virtual methods must be stored in the class 
object instance.

>  Because of limitations of static
> initializers in C, some of this pointers cannot be initialized
> (especially method inheritance I could not implement statically), so
> classes have to be initialized.  The class descriptor, thus, contains a
> flag that indicates whether the class has been initialized and a pointer
> to the class initialization function.  So, the class descriptor for
> Subhandler_Object contains:
>
>   int           _initialized;
>   void(*_init_class)();
>   char *        name;
>   _Descriptor(SUPCLASS) *       sup;
>   void(*destroy)(CLASS *this);
>
> Here, destroy is the only real method that is defined at this level and
> is inherited or refined by other classes that add more fields here.

I don't like the idea of having an initialized field in the class. Wouldn't it 
be better to use an accessor function ? Something like

SHClass get_some_subhandler_class(void)
{
    static SHClass *class = NULL;

    if ( class == NULL )
    {
        ... initialize the class here ...
    }

    return class;
}

> As far as properties go, at this level the only property defined is a
> pointer to the class descriptor struct:
>
>    _Descriptor(CLASS) *_class;
>
> Then, instance and class method calls are made easier with the help of
> the following macros:
>
> #define _MCALL(object, method, ...) (object->_class->method(object,
> ##__VA_ARGS__)) #define _CCALL(class, method, ...)
> (_Class(class).method(&_Class(class), ##__VA_ARGS__))
>
> I think the above use with __VA_ARGS__ is C99-compliant and does not
> require GNU extensions. I would hate to have to define _MCALL, _MCALL1,
> _MCALL2 and so on.

If we only store pointers to virtual methods in the class structure, what 
about defining wrapper methods to them ? We could even inline the wrapper 
methods.

> There is a double indirection to get to the real method address, but I
> am counting on the compiler optimization and I think that, anyway, the
> overhead  will be dwarfed by the cost of the lack of inlining.

Once again, the double indirection overhead would only occur for virtual 
methods, which is also the case in C++ anyway.

> > Most OO-oriented frameworks written in plain C (Gtk+/Gnome comes to mind
> > immediately) Don't use underscores in the name of the classes. Shouldn't
> > we stick to the same rules (for letter of each work in uppercase for
> > class names, without underscores, and lowercase with underscores for
> > members and functions).
>
> I have no preference on that.  I am happy to change if it makes things
> clearer.

I don't have a lot of experience with gtk+, so I don't really care, but I 
think that it will be easier to attract developpers if we stick to a the gtk+ 
coding rules.

Laurent Pinchart