On Sun, Mar 16, 2014 at 3:29 PM, Nick Wellnhofer <[email protected]> wrote:
>> Would it help to install a symlink for the most recent version?
>>
>> $INCLUDE/Foo # symlink to $INCLUDE/Foo-3.3.1
>
> Yes, but it shouldn't make a noticable difference.
If CFC ever supports partial compilation (individual Clownfish files rather
than whole parcels), might performance start to matter more? Having a
deterministic location to look for a specific class can't hurt.
I agree that a layout which facilitates uninstallation is desirable.
> But there's a lot more happening in these examples. It seems that you want
> to merge parcel and class namespaces. What we have now:
>
> Parcel: lucy
> Class: Lucy::Index::Indexer
>
> How I understand your proposal:
>
> Parcel: org.apache.lucy
> Class: org.apache.lucy.index.Indexer
>
> The basic approach looks great. The only question is how to map the
> Clownfish names to the host language and to C symbols.
This is a hard but interesting problem. Different host language communities
have different conventions, and it is impossible to create a lowest common
denominator default for Clownfish which works for all of them.
Python:
import lucy
indexer = lucy.index.Indexer(index='/path/to/index')
from lucy.index import Indexer
indexer = lucy.index.Indexer(index='/path/to/index')
Ruby:
require "lucy"
indexer = Lucy::Index::Indexer.new(:index => '/path/to/index')
Perl:
use Lucy::Index::Indexer;
my $indexer = Lucy::Index::Indexer->new(index => 'path/to/index');
Java:
import org.apache.lucy.index.Indexer;
...
Indexer indexer = new Indexer("/path/to/index");
import org.apache.lucy.index.*
...
Indexer indexer = new Indexer("/path/to/index");
Go:
import "lucy.apache.org/lucy"
...
indexer := lucy.NewIndexer("/path/to/index")
To achieve our goal of facilitating idiomatic bindings, we will need to
support customizable mapping for module/class/package names just as we support
customizable method names. Since the Clownfish internals use class objects
much more often than class names, making class names customizable ought to be
doable.
Let's consider modifying the syntax for Clownfish class declarations. We
already impose the constraint that the last "component" of each class name
must be unique within a parcel (since we used that for the struct name). That
effectively imposes a flat namespace within each parcel. How about making
the class name just an identifier rather than a qualified name?
// `Indexer` instead of `Lucy::Index::Indexer` or other alternatives.
parcel org.apache.lucy;
public class Indexer { ... }
Now this option for import syntax makes more sense (especially with a
parcel-centric include dir layout):
from org.apache.lucy use Indexer, IndexSearcher;
Unfortunately, one drawback of this approach is that it that it would make it
more difficult to know where a given class lives in the hierarchy.
("Indexer.cfh" might appear under "lucy/", under "lucy/index/", under
"lucy/index/foo/bar/baz/" or wherever.) As a result, it's not obvious what
`.h` file to `#include` in C code.
If we were to put a mapping from class name to filepath for all (nested?)
public classes in the parcel file JSON, similar to the "provides" key in
META.json, that would help CFC to find the right `.cfh` file. But it still
doesn't solve the problem for users who need to `#include` the right `.h`
header...
Marvin Humphrey
