lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <mar...@rectangular.com>
Subject Re: [lucy-dev] Hiding struct defs
Date Thu, 12 Apr 2012 00:49:46 GMT
On Wed, Apr 11, 2012 at 10:40 AM, Nick Wellnhofer <wellnhofer@aevum.de> wrote:
> On 11/04/2012 19:09, Marvin Humphrey wrote:

>>   * cfish_bootstrap_parcel() will need a per-parcel name, I think.
>
> Yes, but I couldn't find a way to get the parcel name from the CFCBind*
> classes. It looks like it's only available to the CFCPerl* classes.

I'd suggest a hack along these lines for now:

Index: clownfish/src/CFCBindCore.c
===================================================================
--- clownfish/src/CFCBindCore.c	(revision 1324986)
+++ clownfish/src/CFCBindCore.c	(working copy)
@@ -114,8 +114,10 @@
 static void
 S_write_parcel_h(CFCBindCore *self) {
     CFCHierarchy *hierarchy = self->hierarchy;
+    CFCParcel    *parcel    = NULL;

     // Declare object structs for all instantiable classes.
+    // Obtain parcel prefix for use in bootstrap function name.
     char *typedefs = CFCUtil_strdup("");
     CFCClass **ordered = CFCHierarchy_ordered_classes(hierarchy);
     for (int i = 0; ordered[i] != NULL; i++) {
@@ -125,7 +127,13 @@
             typedefs = CFCUtil_cat(typedefs, "typedef struct ", full_struct,
                                    " ", full_struct, ";\n", NULL);
         }
+        if (parcel && CFCClass_get_parcel(klass) != parcel) {
+            CFCUtil_die("Multiple parcels not yet supported.");
+        }
+        parcel = CFCClass_get_parcel(klass);
     }
+    const char *parcel_prefix = parcel
+                                ? CFCParcel_get_prefix(parcel) : "cfish_";
     FREEMEM(ordered);


>>   * In VTable_bootstrap, why not just have self->name be an ordinary
>>     CharBuf rather than a ViewCharBuf?  OH!  HAHAHA!  Not bootstrapped yet!
>>     XD
>
> It could also be a CharBuf, but the object has to be created manually, since
> the VTables aren't set up yet.

Cool cool... Now that I take a closer look, IMO it definitely ought to be a
CharBuf because it needs to duplicate the string that comes in.  If we don't
do that, then that ViewCharBuf will be stuck holding a pointer to a passed in
"const char*" argument -- which is a problem because what if it goes away?

(The word "View" in ViewCharBuf is supposed to communicate that the object
doesn't own its own string -- so use with caution!  ZombieCharBufs, which
subclass ViewCharBuf, also have this trait.)

Marvin Humphrey

Mime
View raw message