On 28/05/2013 06:10, Marvin Humphrey wrote:
Yes, it's to make our namespacing mechanism more robust. However, it's not
that Clownfish should *force* users into lengthy parcel names -- its that we
should support namespaces properly and give users a choice. Even after we
enable nested parcel names, people can still select simple names, or avoid
explicit parcels altogether. Using reversed domain names is only a
convention.
Prefixes are flawed, because anything more than a few characters results in
symbols which are unacceptably cumbersome to type, but the limited length
makes clashes more likely. For example, when we were considering what
Clownfish ought to use as a prefix, we had to take into account that "CF" is
used as a prefix by Apple's "Core Foundation" classes.
We're already committed to providing short name aliases for the sake of
programmer convenience. We may as well go one step further and build out
namespacing which remains just as user-friendly yet is more resistant to
symbol clashes.
* Individual symbol aliases, which are typed multiple times within source
files, should be short.
* Imports, which happen only once per file, may be long.
* Real names for symbols may be long, since they can remain hidden behind
aliases most of the time.
To support namespaces properly in the Clownfish internals, we need to ensure
that we don't lock systems into place that depend on prefixes within global
contexts -- which is why the commit in question drew my attention. We were
already doing doing something similar elsewhere -- the "boot" files e.g.
"lucy_boot.c" and "lucy_boot.h" -- and I was the one who wrote that code. But
those were either a bug or a TODO (take your pick) -- and rather than compound
the mistake, we should fix it... by differentiating autogenerated files using
directory structures rather than file name prefixes.
These are all valid points. 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 ;)
However, I would like to suggest a tweak. A common complaint in Java-land is
that the reverse-domain package naming convention results in too deep a
directory hierarchy. The extra depth is not a huge deal for installed files,
but it's a pain when interacting with source trees. I think we can solve this
by having CFC allow .cfp parcel files to establish the namespace for files in
lower directories:
// This...
$CORE/
foo.cfp // com::example::foo
$CORE/foo/
MyClass.cfh // com::example::foo::MyClass
// Not this...
$CORE/com/example/
foo.cfp
$CORE/com/example/foo/
MyClass.cfh
+1
(Aside: We may want to go with '.' instead of '::' ourselves.)
+1
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?
(Another aside: perhaps we should enable short names by default and replace
`LUCY_USE_SHORT_NAMES` with `LUCY_NO_SHORT_ALIASES`.)
+1
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.
FWIW, there's definitely some bloat in those headers.
Also, we could address your concern about embedded C code taking up too much
space in the headers by generating a file called e.g. "parcel.impl" which gets
pulled in conditionally:
#ifdef P_ORG_APACHE_LUCY
#include "org/apache/lucy/parcel.impl"
#endif
I think most of the bloat comes from the method wrappers. It shouldn't
be a problem if headers are included selectively.
Nick
