# from Adam Kennedy
# on Sunday 03 January 2010 18:14:
>That is not to say, of course, that we don't want _fragmented_ indexes
>as a separate performance feature.
They should be partitioned for the sake of JFDI. Otherwise, we're
probably going to block on trying to redo the p5 index and p6 support
won't happen.
Not: "let's make them wildly incompatible", just: p5 doesn't _need_ to
change right now, but p6 needs to happen soon and we can make
unification later by playing catchup with the p5 parts.
>> An index with support for $n languages doesn't seem to
>> gain much over $n similarly structured indexes.
>
>If Parrot itself supports trans-language calls (which I'm led to
>understand it can?) then a single index gives us the potentially huge
>win of cross-language dependencies.
Does it? Tell me how the second API should work and how to build that
index:
look_in_index($language, $name, $author, $version);
look_in_index($name, $author, $version);
That is, a trans-language system could/should deal with this by making
one call for each $language or otherwise providing its own abstraction
around the multiple indexes. If you're require()ing only by-namespace,
you have to deal with the "from any language" case with some preferred
order. (And it looks like perl6 says you have to say from:<$lang> to
get at another language anyway.)
If you can have duplicate entries per namespace+language, it's not much
of an "index" vs the equivalent of having a partition per language and
unique constraint on each namespace per partition.
Or, Ricardo gets to keep Config::INI and Curtis has to wait for p5
support in parrot?
--Eric
--
You can't whack a chisel without a big wooden mallet.
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
