On Tue, May 28, 2013 at 3:42 AM, Nick Wellnhofer <[email protected]> wrote:
> I'd only like to add that there probably won't be that many Clownfish
> parcels in the foreseeable future. Or, in other words, I would be happy if
> we had so many Clownfish users that they would start to complain about
> symbol clashes ;)

Heh. ;)  Hence, my failed attempt to address prefixing as an aside at first
rather than an imperative that needed to be attended to immediately.  But then
when it appeared we might have substantially different long-term visions, I
figured it was worth investing some time to reconcile them.

>> In terms of alias generation, here's what I think we should be doing:
>>
>>      #define lucy_Indexer_new org_apache_lucy_Indexer_new
>
> But if we define this unconditionally, doesn't it defeat the purpose of
> fully-qualified names?

Yeah, I suppose that it does -- if conflicting Clownfish-powered libraries are
both pound-included in the same source file.  However, at least the macro
aliases are not visible from compiled object files or later stages.

>>  From the perspective of a programmer working with Clownfish, everything in
>>  a parcel should be available with via a single pound-include:
>>
>>      #include "org/apache/lucy.h"
>
> Note that this would possibly pull in megabytes of mostly unused header
> files for every source file. This might result in a noticable compilation
> slowdown.

Maybe so, but...

*   Lucy is pretty big.
*   You'll almost always want everything from the Clownfish core.
*   Things have been skewed up till now because the test class headers have
    also been included.
*   It may be possible to cut down the size of those headers substantially.

> I think most of the bloat comes from the method wrappers.

I'm pretty sure that's right.  Perhaps the "thunk method wrappers" proposal
can help.

> It shouldn't be a problem if headers are included selectively.

I haven't yet given up on the idea of maintaining multiple major versions and
having one header which points to the latest.  I'm envisioning that
"org/apache/lucy.h" would consist of a single line:

    #include "org/apache/lucy/0/parcel.h"

Things get more complicated if individual files have to specify versions in
the directory structure.  I don't really want to inflict this on users:

    #include "org/apache/lucy/0/search/IndexSearcher.h"

Maybe the approach won't work out, but it's worth a try.

Marvin Humphrey

Reply via email to