On Thu, Apr 12, 2012 at 2:58 AM, Nick Wellnhofer <[email protected]> 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:
void
lucy_init_parcel(void) {
lucy_Bool_init_class();
lucy_Hash_init_class();
}
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:
void
cfish_init_parcel(void) {
cfish_Bool_init_class();
cfish_Hash_init_class();
}
void
lucy_init_parcel(void) {
}
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
