Mailing-List: contact lucy-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: lucy-dev@lucene.apache.org
Received-SPF: pass (herse.apache.org: domain of dbalmain.ml@gmail.com
 designates 66.249.92.173 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Yj1gAGyKb26j10ujQ6ldHfm+C9ofCVP25wGKq7DhOe+CFIYiXgy5cDeBIRy4Dd+FtcoGIBhT8HCA7p4IffHUSUJimFQWOkq+ETd7tlKwuOaHGf3/Wl0nWejIxR3LiI7q28phtTc3Xu4UnvzhjU9aj5GqLBvLabRSyKwfRuyuggM=
Message-ID: <d792e0dc0612211451l6ec105d5y277b830fd3915ab3@mail.gmail.com>
Date: Fri, 22 Dec 2006 09:51:09 +1100
From: "David Balmain" <dbalmain.ml@gmail.com>
To: lucy-dev@lucene.apache.org
Subject: Re: OO Design -- initialization
In-Reply-To: <CFD45F19-784F-4AE8-907F-E8BCCA101C70@rectangular.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <E347CEFF-99F8-43A8-A900-D93C914747F9@rectangular.com>
	 <d792e0dc0610231844o26348ba1j1d73a08e159e026a@mail.gmail.com>
	 <48066BF6-6AE9-4525-A345-B1C86790300C@rectangular.com>
	 <d792e0dc0612182306h2c6a1854r612bbf6be2941fc1@mail.gmail.com>
	 <CFD45F19-784F-4AE8-907F-E8BCCA101C70@rectangular.com>

On 12/21/06, Marvin Humphrey <marvin@rectangular.com> 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/