incubator-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] Rethinking header file installation
Date Sun, 11 Mar 2012 23:41:33 GMT
On Sun, Mar 11, 2012 at 3:10 PM, Nick Wellnhofer <wellnhofer@aevum.de> wrote:
> Like a typical extension, my dummy extension subclassed a Lucy core class.
> So the Clownfish compiler tried to find the definition of the parent class
> and its ancestors. This broke down because the .cfh files of those Lucy core
> classes hadn't been loaded.

Hahaha, yes -- I hadn't considered that you'd build your extension using
the Clownfish compiler!

> I'm only starting to understand the details of Clownfish, but it seems to me
> that there's no way around installing all the .cfh files to make subclassing
> work in extensions.

FWIW, it is technically feasible to provide a limited pure C subclassing API.
Take a look at Lucy::Test::Store::TestFileHandle, where we create a subclass
of Lucy::Store::FileHandle at runtime and override one method
(<http://s.apache.org/ZbP>):

    VTable *vtable = VTable_fetch_vtable((CharBuf*)klass);
    if (!vtable) {
        vtable = VTable_singleton((CharBuf*)klass, FILEHANDLE);
    }
    VTable_Override(vtable, S_no_op_method, Lucy_FH_Close_OFFSET);

However, this mechanism only provides support for overriding methods.  Among
other things, you can't extend the parent struct to add member variables.

> Thinking further, we could do away with installing the auto-generated C
> headers, and regenerate them from the .cfh files when building an extension.
> The Clownfish headers are also much smaller: 600 KB compared to 4 MB for the
> C headers.

Technically, this will work.  The output of CFC for a given set of .cfh files
is deterministic.

CFC is also nice and fast now that it's been ported to C.  It takes 2.5
seconds to parse and generate all those files on my 4-year-old MacBook pro.

> So is there any compelling reason to install C headers at all?

Nope!

My only concerns are about API expansion and ABI stability:

  * We will have to install CFC and provide some sort of an experimental API
    for both the Clownfish language and CFC.
  * For the time being, we will not be able to add member variables without
    breaking ABI compatibility.  New methods and classes are OK, but not new
    member vars.

I think we can promise not to break ABI compatibility with any bugfix release.
So long as you and your users are clear that you will need to recompile your
extension each time Lucy makes a minor release, we should be OK.  (IMO, we
should consider should building in a version check to force the issue.)

Personally, I believe that these are all positive developments for the
project, so +1 to install the .cfh files instead of the autogenerated .h
files.

Marvin Humphrey

Mime
View raw message