On Jan 5, 2013, at 04:22 , Marvin Humphrey <[email protected]> wrote:
> 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);
This works well for the C bindings but I was thinking more about other host
languages. callbacks.h should be identical for all of them, so it would be nice
if the code that generates the file doesn't have to be duplicated.
> 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.
Yes, that's my plan.
> 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);
What if a user really wants to pass a CharBuf? Maybe be should offer additional
_Str methods where it makes sense. Something like Hash_Fetch_Str which we
already have.
> 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);
I like the idea.
Nick
