On Mar 16, 2014, at 03:01 , Marvin Humphrey <[email protected]> wrote:
> I think we also should consider changing Clownfish to require that .cfh files
> contain at most one public class and that their location within the directory
> tree correspond to that class. That's a fairly significant change, but it
> yields a number of benefits:
>
> * It's easier to reason about parcels and Clownfish include dirs.
> * It is always clear what .h file you need to #include within C code.
> * It's possible to discover that a parcel does *not* contain a given public
> class simply by inspecting the file system, rather than compiling all .cfh
> files which belong to the parcel.
> * Finding the .cfh file which contains a given public class is
> straightforward.
+1
This would be useful for an import mechanism.
> With that in mind, here's one possibility for file layout within a Clownfish
> include directory:
>
> All files and directories below a .cfp file belong to the specified
> parcel, unless preempted by a .cfp file in a subdirectory.
>
> In the following directory listing, there are two packages, `foo` and
> `foo.bar`:
>
> $INCLUDE
> $INCLUDE/foo
> $INCLUDE/foo/bar
> $INCLUDE/foo/bar/Gizmo.cfh
> $INCLUDE/foo/bar.cfp # parcel foo.bar
> $INCLUDE/foo/Thing.cfh
> $INCLUDE/foo/Widget.cfh
> $INCLUDE/foo/defs.h
> $INCLUDE/foo.cfp # parcel foo
>
> The files `Thing.cfh` and `Widget.cfh` belong to the parcel `foo`, as does
> the C header file `defs.h`.
>
> The file `Gizmo.cfh` belongs to the parcel `foo.bar`.
>
> For the sake of argument, here's another possible layout which supports
> multiple versions per past discussions.
>
> $INCLUDE
> $INCLUDE/foo
> $INCLUDE/foo/bar/0
> $INCLUDE/foo/bar/0/Gizmo.cfh
> $INCLUDE/foo/bar/0/_parcel.cfp # parcel foo.bar 0.x
> $INCLUDE/foo/bar/1
> $INCLUDE/foo/bar/1/Gizmo.cfh
> $INCLUDE/foo/bar/1/_parcel.cfp # parcel foo.bar 1.x
> $INCLUDE/foo/1/Thing.cfh
> $INCLUDE/foo/1/Widget.cfh
> $INCLUDE/foo/1/defs.h
> $INCLUDE/foo/1/_parcel.cfp # parcel foo 1.x
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.
> Honestly, I may be ready to give up on that feature. As much as I think that
> library versioning is a pressing problem in the world of computer science,
> supporting multiple library versions simultaneously at runtime is very
> involved and not central to the mission of a "symbiotic object system". Maybe
> we just make incremental progress on the versioning problem by formalizing the
> format and ordering of Clownfish version numbers and call it a day.
+1, this is low-priority.
> Another related issue is that we want to allow the parcel `com.example.stuff`
> to be located at the top of a source directory, in order to avoid
> inconveniently deep source trees (such as those which afflict many Java
> projects). How about we support that by searching two places for the .cfp
> file corresponding to the parcel `com.example.stuff`?`
>
> 1. `$INCLUDE/com/example/stuff.cfp`
> 2. `$INCLUDE/com.example.stuff.cfp`
>
> Such behavior would facilitate development directory trees like this:
>
> core
> core/com.example.stuff.cfp
> core/com.example.stuff.tripe.cfp
> core/stuff
> core/stuff/Doodad.c
> core/stuff/Doodad.cfh # class com.example.stuff.Doodad
> core/stuff/Gadget.c
> core/stuff/Gadget.cfh # class com.example.stuff.Gadget
> core/tripe
> core/tripe/Junk.c # class com.example.stuff.tripe.Junk
> core/tripe/Junk.cfh
>
> The deep directory structure would be checked first. A parcel file named
> `com.example.stuff.cfp` would be installed as `com/example/stuff.cfp`.
Good idea but I’m not really sold on hierarchical parcel names yet.
>> Another thing I'd like to do is to get rid of the "default" parcel.
>
> So... every .cfh file will need to start with a parcel statement?
>
> +0
>
> It's a little more boilerplate for simple stuff but OK. It's also something
> which could theoretically be relaxed later.
>
> The CFC implementation code for the "default" parcel is pretty kludgy IIRC, so
> I'm guessing at least part of the motivation is cleanup? Go for it.
I simply don’t see how the default parcel could be useful in a real-world
project. We’d have to allow classes from different projects in the default
parcel which is different from the way other parcels are handled. Also, using
classes in the default parcel as prerequisite wouldn’t really work.
The only use right now is to simplify some tests but it also led me to
introduce subtle bugs in the test suite.
Besides, there aren’t any end-to-end tests for the default parcel. I wouldn’t
be surprised if we’d still have to fix a couple of corner cases to fully
support it.
Nick
