lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Wellnhofer <>
Subject Re: [lucy-dev] Hiding struct defs
Date Thu, 12 Apr 2012 09:58:47 GMT
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_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.


View raw message