incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: OO Design -- initialization
Date Thu, 21 Dec 2006 03:01:20 GMT

On Dec 18, 2006, at 11:06 PM, David Balmain wrote:

> Actually, I like this more than the code below. To me the braces help,
> not hinder. But to each his own I guess. Also, we could macrofy this
> if wanted to;
>        #define DOG_DATA(name) {\
>            name,\
>                (Animal_speak_t) Dog_speak,\
>                (Animal_eat_t)   Dog_eat\
>            },\
>            Dog_chase_cats
>        /* in Animal/Dog.c */
>        const DOG DOG_CLASSDATA = {
>            DOG_DATA("Animal::Dog")
>        };
>        /* in Animal/Dog/PitBull.c */
>        const PIT_BULL PIT_BULL_CLASSDATA = {
>            {
>                DOG_DATA("Animal::Dog::PitBull")
>            },
>            PitBull_chase_humans
>        };

It turns out that we don't have to resort to manual intervention like  
this at all. generates a model of the complete inheritance  
hierarchy.  Each class is represented by a Class object which knows  
its parent, its children, its member variables, its class functions,  
and its instance methods, including which methods are inherited or  

With that information in hand, it's possible to resolve all inherited  
members, both for the object struct defs and for the virtual table  
struct defs.

It might be a smidge faster.  More importantly, it's oodles easier to  
maintain and there's a lot less potential for error when this stuff  
gets handled automatically.

> With macros I don't think it makes that much difference but I'm sure
> you'll be able to enlighten me as to where my macro example fails, in
> which case, bootstrapping is fine with me. When you said bootstrapping
> initially I was think memory allocation but if that isn't happening
> then I don't have a problem with it.

Prodded by your discontent, I built a solution which resolves the  
virtual tables at compile time. :)  They're const.  No bootstrapping.

> I feel the same way but Valgrind + Ruby = :(.

Bummer.  Well, at least Perl works with Valgrind on Linux, so we'll  
be able to run all wrapped C tests that way.

> This is one of the
> things that got me thinking about building a database like search
> engine which runs in a separate process to Ruby as a server, but that
> is a whole other story.

If we allow the user to specify the serialization of Document, Lucy  
becomes an object database.  :)

Marvin Humphrey
Rectangular Research

View raw message