On 12/04/2012 06:10, Marvin Humphrey wrote:
What I would really like to do with those is initialize them during the
per-class bootstrapping you've been coding up.

A user-defined per-class initialization function sounds very useful. 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

To achieve this, I imagine that we could store a bootstrapping routine as a
global function in the per-class autogenerated .h files, enabled with a
pound-define.  Something like this...

In autogen/Lucy/Object/Hash.h:

     #ifdef LUCY_HASH_WANT_BOOT
     void
     lucy_Hash_bootstrap(void) {
         // ...
         LUCY_HASH
             = cfish_VTable_bootstrap(LUCY_HASH, LUCY_OBJ,
                                      "Lucy::Object::Hash", obj_alloc_size,
                                      x, size, callbacks, methods);

(Not every VTable will be bootstrapped at this point, so it's not safe to call the aux_boot code.)

     #ifdef LUCY_HASH_AUX_BOOT
         LUCY_HASH_AUX_BOOT();
     #endif
         return LUCY_HASH;
     }
     #endif // LUCY_HASH_WANT_BOOT

In core/Lucy/Object/Hash.c:

     #define LUCY_HASH_WANT_BOOT
     #define LUCY_HASHTOMBSTONE_WANT_BOOT
     #define LUCY_HASHTOMBSTONE_AUX_BOOT S_tombstone_aux_boot
     #include "Lucy/Object/Hash.h"

     static void
     S_tombstone_aux_boot(void) {
         TOMBSTONE.vtable    = HASHTOMBSTONE;
         TOMBSTONE.ref.count = 1;
     }

That's kind of messy, but do you see where I'm going with this?  Each class
gets an optional bootstrapping routine that it can hook into to do whatever it
wants.

+1 for the general idea. I also don't see a cleaner solution unless we start to generate additional files.

The punchline is that I believe we will ultimately be able to hide all of our
method implementations by making them static.

That would be nice.

Nick

Reply via email to