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 04:10:51 GMT
On Wed, Apr 11, 2012 at 10:40 AM, Nick Wellnhofer <> wrote:
> On 11/04/2012 19:09, Marvin Humphrey wrote:

>>> I also tried to malloc the VTables dynamically, but this broke
>>> RAWPOSTING_BLANK where a VTable is used to initialize a global struct.
>> I've just committed a change that kills off RAWPOSTING_BLANK.
>> I suspect that the ZombieCharBuf EMPTY is also going to get in your way;
>> I'll look into deep-sixing that one later today.
>> There may be others; we'll just address them one-by-one until we can malloc
>> dynamically.
> OK.

Several of these are now gone.  A couple known instances remain.

>From core/Lucy/Object/Hash.c:

    static HashTombStone TOMBSTONE = {

>From core/Lucy/Object/Num.c:

    static ViewCharBuf true_string  = { VIEWCHARBUF, {1}, "true",  4, 0 };
    static ViewCharBuf false_string = { VIEWCHARBUF, {1}, "false", 5, 0 };
    static BoolNum true_obj  = { BOOLNUM, {1}, true, &true_string };
    static BoolNum false_obj = { BOOLNUM, {1}, false, &false_string };

What I would really like to do with those is initialize them during the
per-class bootstrapping you've been coding up.

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:

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

In core/Lucy/Object/Hash.c:

    #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

The punchline is that I believe we will ultimately be able to hide all of our
method implementations by making them static.  If we can pull that off, it
will help us in two ways:

  1. It will cut down significantly on the number of exported symbols
the dynamic
     linker has to deal with.
  2. It will make it impossible for a user to make the mistake of invoking the
     implementing function instead of the method through accidental
     miscapitalization (as multiple Lucy PMC members have done when starting

Marvin Humphrey

View raw message