On Mar 16, 2014, at 20:58 , Marvin Humphrey <[email protected]> wrote:
> On Sun, Mar 16, 2014 at 10:00 AM, Nick Wellnhofer <[email protected]> wrote: >> I had something like this in mind: >> >> $INCLUDE/Foo-2.2.0/Foo.cfp >> $INCLUDE/Foo-2.2.0/Foo/Gizmo.cfh >> $INCLUDE/Foo-3.3.1/Foo.cfp >> $INCLUDE/Foo-3.3.1/Foo/Gizmo.cfh >> $INCLUDE/Bar-0.1.0/Bar.cfp >> $INCLUDE/Bar-0.1.0/Bar/Widget.cfh >> >> I think Ruby gems have such a directory structure. This makes it easy to >> uninstall parcels. > > What's the search algorithm? To find the correct parcel, it looks like we'd > have to read the complete $INCLUDE directory contents, parse parcel > identifiers and sort by version -- which might get slow once you have a lot of > packages installed. It should be fast enough for thousands of parcels. > 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. >> Good idea but I'm not really sold on hierarchical parcel names yet. > > Convenient aliasing support in the import mechanism is crucial. Here are some > possible schemes: > > // Make `Indexer` available in the current .cfh file as an alias for > // `org.apache.lucy.index.Indexer`. > use org.apache.lucy.index.Indexer; > > // Make `Indexer` and `IndexSearcher` available. > from org.apache.lucy use Indexer, IndexSearcher; > > // Make `LucyIndexer` an alias for `org.apache.lucy.index.Indexer`. > from org.apache.lucy use Indexer as LucyIndexer; > > // Make `lucy` an alias for `org.apache.lucy`, so that > // `lucy.index.Indexer` and such become valid. > use org.apache.lucy; > > Note that there is interplay between import mechanism syntax and how we lay > out parcel contents in Clownfish include dirs. 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. I think you already made some proposals using fully qualified names in C symbols like ‘org_apache_lucy_index_Indexer_new’ (plus version and a host language tag at some point). This shouldn’t be a problem as long as the short name macros are used (and enabled by default). But how would the mapping to the host language namespace work? >> I simply don't see how the default parcel could be useful in a real-world >> project. > > The motivation is not to facilitate real-world projects, it's to make it > easier to write trivial programs -- especially when learning or writing > documentation and tutorials. > > But in any case, I'm OK with the plan to eliminate the default parcel and > require a parcel statement up front: > > YACC grammar for CFH file organization: > > cfh_file > : parcel_statement import_statements class_defs_or_cblocks > | parcel_statement class_defs_or_cblocks > ; OK, this is something that can be done immediately. Nick
