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.
Would it help to install a symlink for the most recent version?
$INCLUDE/Foo # symlink to $INCLUDE/Foo-3.3.1
> 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.
The reasoning behind the hierarchical parcel names is simply namespace
differentation in a crowded world. It ticks me off that we're not going to be
able to release a Ruby gem named "lucy" because somebody's already published a
gem with that name. IMO, not using hierarchical package names in a modern
open source packaging ecosystem is like building a phone list database without
last names.
> 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
;
Marvin Humphrey
