|  | @@ -1,10 +1,5 @@
 | 
	
		
			
				|  |  | -[[painless-getting-started]]
 | 
	
		
			
				|  |  | -== Getting Started with Painless
 | 
	
		
			
				|  |  | -
 | 
	
		
			
				|  |  | -include::painless-description.asciidoc[]
 | 
	
		
			
				|  |  | -
 | 
	
		
			
				|  |  | -[[painless-examples]]
 | 
	
		
			
				|  |  | -=== Painless Examples
 | 
	
		
			
				|  |  | +[[painless-walkthrough]]
 | 
	
		
			
				|  |  | +=== A Brief Painless Walkthrough
 | 
	
		
			
				|  |  |  
 | 
	
		
			
				|  |  |  To illustrate how Painless works, let's load some hockey stats into an Elasticsearch index:
 | 
	
		
			
				|  |  |  
 | 
	
	
		
			
				|  | @@ -121,7 +116,7 @@ GET hockey/_search
 | 
	
		
			
				|  |  |  
 | 
	
		
			
				|  |  |  
 | 
	
		
			
				|  |  |  [float]
 | 
	
		
			
				|  |  | -===== Missing values
 | 
	
		
			
				|  |  | +==== Missing values
 | 
	
		
			
				|  |  |  
 | 
	
		
			
				|  |  |  `doc['field'].value` throws an exception if
 | 
	
		
			
				|  |  |  the field is missing in a document.
 | 
	
	
		
			
				|  | @@ -198,7 +193,7 @@ POST hockey/_update/1
 | 
	
		
			
				|  |  |  ==== Dates
 | 
	
		
			
				|  |  |  
 | 
	
		
			
				|  |  |  Date fields are exposed as
 | 
	
		
			
				|  |  | -`ReadableDateTime`, so they support methods like `getYear`, `getDayOfWeek` 
 | 
	
		
			
				|  |  | +`ZonedDateTime`, so they support methods like `getYear`, `getDayOfWeek`
 | 
	
		
			
				|  |  |  or e.g. getting milliseconds since epoch with `getMillis`. To use these
 | 
	
		
			
				|  |  |  in a script, leave out the `get` prefix and continue with lowercasing the
 | 
	
		
			
				|  |  |  rest of the method name. For example, the following returns every hockey 
 | 
	
	
		
			
				|  | @@ -365,38 +360,3 @@ Note: all of the `_update_by_query` examples above could really do with a
 | 
	
		
			
				|  |  |  {ref}/query-dsl-script-query.html[script query] it wouldn't be as efficient
 | 
	
		
			
				|  |  |  as using any other query because script queries aren't able to use the inverted
 | 
	
		
			
				|  |  |  index to limit the documents that they have to check.
 | 
	
		
			
				|  |  | -
 | 
	
		
			
				|  |  | -[[modules-scripting-painless-dispatch]]
 | 
	
		
			
				|  |  | -=== How painless dispatches functions
 | 
	
		
			
				|  |  | -
 | 
	
		
			
				|  |  | -Painless uses receiver, name, and https://en.wikipedia.org/wiki/Arity[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
 | 
	
		
			
				|  |  | -https://en.wikipedia.org/wiki/Multiple_dispatch[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 whitelists classes from the Java
 | 
	
		
			
				|  |  | -standard library. For example, in Java and Groovy, `Matcher` has two methods:
 | 
	
		
			
				|  |  | -`group(int)` and `group(String)`. Painless can't whitelist 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:
 | 
	
		
			
				|  |  | -
 | 
	
		
			
				|  |  | -1. It makes operating on `def` types simpler and, presumably, faster. Using
 | 
	
		
			
				|  |  | -receiver, name, and arity means that when Painless sees a call on a `def` 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 with `def`
 | 
	
		
			
				|  |  | -typed parameters.
 | 
	
		
			
				|  |  | -2. 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.
 | 
	
		
			
				|  |  | -3. 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.
 | 
	
		
			
				|  |  | -
 | 
	
		
			
				|  |  | -include::painless-debugging.asciidoc[]
 | 
	
		
			
				|  |  | -
 | 
	
		
			
				|  |  | -include::painless-execute-script.asciidoc[]
 |