On Fri, Jan 4, 2013 at 3:16 PM, Nick Wellnhofer <[email protected]> wrote:
> AFAICS, we won't need any callbacks for the C bindings.
> So my idea was to move the callback declarations from parcel.c to a separate
> callbacks.h header file. Then the C bindings can use a dummy version of
> callbacks.h which defines every callback symbol to NULL. But I'm not sure
> where's the best place to decide which version gets written. I see the
> following possibilities:
>
> 1. Add a flag to CoreBind and let this class write callbacks.h accordingly.
> I chose this approach in my c-bindings-wip1 branch.
>
> 2. Let the host language code in CFC trigger the creation of callbacks.h.
> This would probably mean to instantiate another temp CoreBind object in
> the host language code for this task.
>
> Thoughts?
If I understand you correctly, +1 for the second option, yielding something
like this in cfc.c:
CFCC *c_binding = CFCC_new(hierarchy, parcel, header, footer);
CFCC_write_callbacks(c_binding); // <------- callbacks.h written here
CFCC_write_boot(c_binding);
CFCC_write_bindings(c_binding);
What we're missing are the equivalents of the CFCPerl* modules for C.
CFCPerl.c
CFCPerl.h
CFCPerlClass.c
CFCPerlClass.h
CFCPerlConstructor.c
CFCPerlConstructor.h
CFCPerlMethod.c
CFCPerlMethod.h
CFCPerlPod.c
CFCPerlPod.h
CFCPerlSub.c
CFCPerlSub.h
CFCPerlTypeMap.c
CFCPerlTypeMap.h
C is just another host language. We don't need to port all of those CFCPerl*
modules to CFCC* -- but we'll need to port some of them.
In my view, it would be best if we could avoid changing up any behaviors of
the CFCBind* modules, so that they generate exactly the same output regardless
of host. That way, each suite of host-binding modules has to implement more
or less the same functionality to solve the same set of problems.
For example, in addition to factoring the dummy-callback-generating code out
of CFCBindCore, it would make sense to factor the manpage-generating code out
of CFCBindClass and CFCBindCore into new modules named CFCCClass and
CFCCManpage -- the analogues to CFCPerlClass and CFCPerlPod.
One other big concern we will have to address is support for C's native string
format, the NUL-terminated array of char. From Perl, you would never know
that most Lucy methods which accept string arguments actually take a CharBuf
-- and we like it that way. Can you imagine if we made our Perl users write
stuff like this?
my $field_name = Clownfish::CharBuf->new("title");
$schema->spec_field(name => $field_name, type => $type);
Similarly, I don't expect C users to be very happy if we make them do stuff
like this:
cfish_CharBuf *field_name = cfish_CB_newf("title");
Lucy_Schema_Spec_Field(schema, field_name, type);
CFISH_DECREF(field_name);
One possibility is to autogenerated idiomatic wrapper functions which take C
strings:
CLucy_Schema_Spec_Field(schema, "title", type);
Another possibility is to take inspiration from Objective-C and provide a
string literal constructor idiom which does not require taking ownership of a
refcount. (We'd have to intern the strings at the global level since we don't
support autorelease pools, so this approach has significant drawbacks.)
Lucy_Schema_Spec_Field(schema, CFISH_INTERN("title"), type);
In any case, I don't think we should hold up 0.4.0 for these enhancements. My
one main concern is just that we make it clear that the C API is
experimental and subject to change.
Marvin Humphrey
