lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: [lucy-dev] Hiding struct defs
Date Thu, 12 Apr 2012 16:14:03 GMT
On Thu, Apr 12, 2012 at 2:58 AM, Nick Wellnhofer <> wrote:
> A user-defined per-class initialization function sounds very useful.

Here's a refinement: Instead of providing per-class initialization support, we
can support a single per-parcel initialization function.

Here's how we might implement such a function right now:

    lucy_init_parcel(void) {

Only a handful of classes will typically require bootstrapping.  This way we
can avoid that messy pound-define-enabling I proposed before.  (At least for
the auxilliary bootstrapping -- we'll probably still need it for VTable
bootstrapping if we want static function method implementations.)

Once we break out Clownfish and Lucy::Test as separate parcels, then the
parcel initialization functions might look like this:

    cfish_init_parcel(void) {

    lucy_init_parcel(void) {

    lucytest_init_parcel(void) {

> But these functions might make use of other VTables that haven't been
> bootstrapped yet. So we should't call them during bootstrapping but rather
> afterwards. For example, I initially tried to register the VTables at the
> end of VTable_bootstrap which failed for this reason when trying to call
> some LFReg methods.
> We might even have to delay the per-class initialization until after all
> VTables have been registered, so the sequence would be:
> 1. Bootstrap all VTables
> 2. Register all VTables
> 3. Initialize all classes

+1, sounds good. (With the refinement to step 3 proposed above.)

I'm imagining that this sequence would be repeated for each parcel load.

The mechanism will have to incorporate per-host logic, but the common behavior
can be defined as part of the Clownfish interface.

Marvin Humphrey

View raw message