Hi,

Paul Brannan <pbrannan / atdesk.com> wrote:
> given a Derived, you can cast up to a Base without worrying about the
> exact structure of your class hierarchy:
>   Derived *d = malloc(sizeof(Derived));
>   Base *b = (Base*)d;

Thanks for giving the excellent idea on doing the object-orientation on
the data part without deferencing.  I like it very much.  In fact, I just
asked a similar question on comp.lang.c several weeks ago.

> Also, note that you don't need a function pointer for the mark and free
> functions, unless each instance gets its own mark or free function.  The
> mark and free functions should be associated with the object's class,
> not the instance of the class.  With a good naming system, some macros,
> and the ## operator, you can almost hide them completely.

Regarding this, I am not so sure.  Under arbitrarily complex nested struct
with a mix of VALUE's and ordinary C data, I think it will be a really
hard work for the great-great-great-grandchildren on defining its mark and
free functions for its class.  With the method that I proposed initially,
I think an inheritance level can just define

    static void mark_me (sMyStruct* s)
    {
        /* mark my own VALUE's */
        ....
        /* mark my parent */
        s->parentMarkFunc (s);
    }

Especially, when the parent Ruby class is never constructed, i.e, its
Data_Wrap_Struct() is never called, we have to do it this way, don't we?

(In Ruby, rb_obj_call_init() is propagated through all the parents, but
isn't that for each class Data_Wrap_Struct() is usually called before
rb_obj_call_init()?  In other words, calling rb_obj_call_init() may not
call all the parents' Data_Wrap_Struct()'s.)

Regards,

Bill