On 9/18/07, Tom Hill <[EMAIL PROTECTED]> wrote: > Hi - > > I'm not sure what you mean by a reflection based approach, but I've been > thinking about doing this for a bit, since we needed it, too.
Reflection could be used to look up and invoke the constructor with appropriately-typed arguments. If we assume only "primitive" types and ValueSources are used, I don't think it would be too hard to craft a drop-in replacement that works with existing implementations. In any case, the more flexible alternative would probably be to do as you're suggesting (if I understand you correctly) -- let the function handle the parsing, with a base implementation and utilities provided. The class names would be mapped to function names in the config file. - Jon > I'd just thought about listing class names in the config file. The functions > would probably need to extend a subclass of ValueSource which will handle > argument parsing for the function, so you won't need to hard code the > parsing in a VSParser subclass. I think this might simplify the existing > code a bit. > > You might have to do a bit of reflection to instantiate the function. Did > you have an alternate approach in mind? Are there any other things this > would need to do? > > Is anyone else working on this? > > Tom > > > > > On 9/18/07, Jon Pierce <[EMAIL PROTECTED]> wrote: > > > > I see Yonik recently opened an issue in JIRA to track the addition of > > pluggable functions (https://issues.apache.org/jira/browse/SOLR-356). > > Any chance this will be implemented soon? It would save users like me > > from having to hack the Solr source or write custom request handlers > > for trivial additions (e.g., adding a distance function), not to > > mention changes to downstream dependencies (e.g., solr-ruby). Perhaps > > a reflection-based approach would do the trick? > > > > - Jon > > >
