- Painless Scripting Language: other versions:
- Painless Guide
- Painless Language Specification
- Painless contexts
- Context example data
- Runtime fields context
- Ingest processor context
- Update context
- Update by query context
- Reindex context
- Sort context
- Similarity context
- Weight context
- Score context
- Field context
- Filter context
- Minimum should match context
- Metric aggregation initialization context
- Metric aggregation map context
- Metric aggregation combine context
- Metric aggregation reduce context
- Bucket script aggregation context
- Bucket selector aggregation context
- Analysis Predicate Context
- Watcher condition context
- Watcher transform context
- Painless API Reference
- Shared API
- Aggregation Selector API
- Aggs API
- Aggs Combine API
- Aggs Init API
- Aggs Map API
- Aggs Reduce API
- Analysis API
- Bucket Aggregation API
- Field API
- Filter API
- Ingest API
- Interval API
- Moving Function API
- Number Sort API
- Painless Test API
- Processor Conditional API
- Score API
- Script Heuristic API
- Similarity API
- Similarity Weight API
- String Sort API
- Template API
- Terms Set API
- Update API
- Watcher Condition API
- Watcher Transform API
- Xpack Template API
How painless dispatches functions
editHow painless dispatches functions
editPainless uses receiver, name, and arity
for method dispatch. For example, s.foo(a, b)
is resolved by first getting
the class of s
and then looking up the method foo
with two parameters. This
is different from Groovy which uses the
runtime types of the
parameters and Java which uses the compile time types of the parameters.
The consequence of this that Painless doesn’t support overloaded methods like
Java, leading to some trouble when it allows classes from the Java
standard library. For example, in Java and Groovy, Matcher
has two methods:
group(int)
and group(String)
. Painless can’t allow both of these methods
because they have the same name and the same number of parameters. So instead it
has group(int)
and namedGroup(String)
.
We have a few justifications for this different way of dispatching methods:
-
It makes operating on
def
types simpler and, presumably, faster. Using receiver, name, and arity means that when Painless sees a call on adef
object it can dispatch the appropriate method without having to do expensive comparisons of the types of the parameters. The same is true for invocations withdef
typed parameters. -
It keeps things consistent. It would be genuinely weird for Painless to
behave like Groovy if any
def
typed parameters were involved and Java otherwise. It’d be slow for it to behave like Groovy all the time. - It keeps Painless maintainable. Adding the Java or Groovy like method dispatch feels like it’d add a ton of complexity which’d make maintenance and other improvements much more difficult.