[
https://issues.apache.org/jira/browse/LUCENE-5207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13766068#comment-13766068
]
Uwe Schindler edited comment on LUCENE-5207 at 9/13/13 12:28 AM:
-----------------------------------------------------------------
Hi, very cool!
I like the elegant parser!
Its also the correct way to do the dynamic classes: 1 class per classloader, so
it can be unloaded easily. The JVM does the same for reflection speedups (it
creates stubs for Method#invoke calls, one stub per classloader). The "Loader"
class is already "policeman-certified" and used by my code, too.
I am not happy about the various raw "signatures" in binary form. I would
rewrite JavascriptFunction to take a java.lang.reflect.Method objects and use
[http://asm.ow2.org/asm40/javadoc/user/org/objectweb/asm/commons/Method.html#getMethod(java.lang.reflect.Method)]
or
[http://asm.ow2.org/asm40/javadoc/user/org/objectweb/asm/Type.html#getMethodDescriptor(java.lang.reflect.Method)]
to get the signature and argument count. The other hardcoded "L/foo/bar" stuff
should be rewritten to use
[http://asm.ow2.org/asm40/javadoc/user/org/objectweb/asm/Type.html#getDescriptor(java.lang.Class)].
I can help with that. By using real reflected types we have the safety that
all methods are syntactically correct and checked at runtime/compile time.
I think we should create a heavy committing branch. I would help, this is too
cool.
was (Author: thetaphi):
Hi, very cool!
I like the elegant parser!
Its also the correct way to do the dynamic classes: 1 class per classloader, so
it can be unloaded easily. The JVM does the same for reflection speedups (it
creates stubs for Method#invoke calls, one stub per classloader). The "Loader"
class is already "policeman-certified" and used by my code, too.
I am not happy about the various raw "signatures" in binary form. I would
rewrite JavascriptFunction to take a java.lang.reflect.Method objects and use
[http://asm.ow2.org/asm40/javadoc/user/org/objectweb/asm/commons/Method.html#getMethod(java.lang.reflect.Method)]
or
[http://asm.ow2.org/asm40/javadoc/user/org/objectweb/asm/Type.html#getMethodDescriptor(java.lang.reflect.Method)]
to get the signature and argument count. The other hardcoded "L/foo/bar" stuff
should be rewritten to use
[http://asm.ow2.org/asm40/javadoc/user/org/objectweb/asm/Type.html#getDescriptor(java.lang.Class)].
I can help with that. My using real reflected types we have the safety that
all methods are syntactically correct and checked at runtime/compile time.
I think we should create a heavy committing branch. I would help, this is too
cool.
> lucene expressions module
> -------------------------
>
> Key: LUCENE-5207
> URL: https://issues.apache.org/jira/browse/LUCENE-5207
> Project: Lucene - Core
> Issue Type: New Feature
> Reporter: Ryan Ernst
> Attachments: LUCENE-5207.patch
>
>
> Expressions are geared at defining an alternative ranking function (e.g.
> incorporating the text relevance score and other field values/ranking
> signals). So they are conceptually much more like ElasticSearch's scripting
> support (http://www.elasticsearch.org/guide/reference/modules/scripting/)
> than solr's function queries.
> Some additional notes:
> * In addition to referring to other fields, they can also refer to other
> expressions, so they can be used as "computed fields".
> * You can rank documents easily by multiple expressions (its a SortField at
> the end), e.g. Sort by year descending, then some function of score price and
> time ascending.
> * The provided javascript expression syntax is much more efficient than using
> a scripting engine, because it does not have dynamic typing (compiles to
> .class files that work on doubles). Performance is similar to writing a
> custom FieldComparator yourself, but much easier to do.
> * We have solr integration to contribute in the future, but this is just the
> standalone lucene part as a start. Since lucene has no schema, it includes an
> implementation of Bindings (SimpleBindings) that maps variable names to
> SortField's or other expressions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
