On Jul 1, 2010, at 8:00 AM, Sean Owen wrote: > 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.
Correct. The issue is w/ Dirichlet (and any other one that does similar things). Looking at it some more, the problem may actually be in the test, as I think it is double wrapping a NamedVector with another NamedVector. Checking further now. > > On Thu, Jul 1, 2010 at 12:17 PM, Grant Ingersoll <gsing...@apache.org> 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.
