I think you're right there. Dirichlet needs a complete description of the type of vector to create. This is not only the concrete implementation type now, but whether it is named. The most immediate solution in that method is to add a "named" flag and wrap the prototype Vector instance created appropriately. That should indeed "just work" from there as far as I can see. That sort of change directly mirrors the change that happened to Vector: now implementations come in named and non-named variations.
I don't see any issue with NamedVector per se but I am not actually sure if you're suggesting there is one. On Thu, Jul 1, 2010 at 12:17 PM, Grant Ingersoll <[email protected]> wrote: > The issue is that all I did was fix how LuceneIterable works (to use > NamedVector) and now Dirichlet is broken. My point is it shouldn't matter > what the implementation of Vector is, it should just work, especially in the > case of NamedVector which is just a lightweight wrapper. I'd argue that the > problem is in Dirichlet in that it constructs its vectors incorrectly by > assuming a particular kind of vector. Furthermore, it needs to be able to > preserve that name across all operations. > > Without the ability to use a NamedVector in many cases, one has no way of > doing anything useful with the output.
