On 12/21/06, Marvin Humphrey <[EMAIL PROTECTED]> wrote:
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.
boilerplater.pl 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
overridden.
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.
I thought this might be the case when I read your first email on
boilerplate.pl. That all sounds perfect.
><snip> complaint about ruby and valgrind unhappiness </snip>
> 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. :)
Yep, I've considered this. :)
--
Dave Balmain
http://www.davebalmain.com/
