Return-Path: Delivered-To: apmail-lucene-lucy-dev-archive@locus.apache.org Received: (qmail 41623 invoked from network); 21 Dec 2006 03:01:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 21 Dec 2006 03:01:46 -0000 Received: (qmail 38144 invoked by uid 500); 21 Dec 2006 03:01:53 -0000 Delivered-To: apmail-lucene-lucy-dev-archive@lucene.apache.org Received: (qmail 38126 invoked by uid 500); 21 Dec 2006 03:01:53 -0000 Mailing-List: contact lucy-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: lucy-dev@lucene.apache.org Delivered-To: mailing list lucy-dev@lucene.apache.org Received: (qmail 38117 invoked by uid 99); 21 Dec 2006 03:01:53 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Dec 2006 19:01:53 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [68.116.38.223] (HELO rectangular.com) (68.116.38.223) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Dec 2006 19:01:42 -0800 Received: from [67.189.26.9] (helo=[10.0.1.3]) by rectangular.com with esmtpa (Exim 4.44) id 1GxEMg-0008xU-GW for lucy-dev@lucene.apache.org; Wed, 20 Dec 2006 19:13:02 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <48066BF6-6AE9-4525-A345-B1C86790300C@rectangular.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marvin Humphrey Subject: Re: OO Design -- initialization Date: Wed, 20 Dec 2006 19:01:20 -0800 To: lucy-dev@lucene.apache.org X-Mailer: Apple Mail (2.752.2) X-Virus-Checked: Checked by ClamAV on apache.org 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. > 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 http://www.rectangular.com/