When people need to serialize in a format that differentiates string concatenation from addition, they can use the new `concat` function in an expression. But I don't think we need to throw if people use `+` with strings.
There are times when we parse from XML without a schema (e.g. KML). In these cases, features attributes will always be strings. We can cast to number when creating literals from symbolizers and then assert `!isNaN` instead of asserting that they are numbers before.
This commit changes the examples to using ol.control.defaults().extend to extend the collection of controls. This is in preparation for a future commit that will remove the 2nd argument to ol.control.defaults. The same is done for ol.interaction.defaults.
Currently the animation functions share the same module, namely ol.animation. We do differently for ol.control.defaults and ol.interaction.defaults, with ol.control.defaults and ol.interaction.defaults module. This commit replaces the ol.animation module by four modules, one for each animation function.
This makes things more consistent, and will make it possible to use the @exportFunction annotation for the exporting of the animation functions.
This commit adds a new export annotation: @exportFunction. @exportFunction is to be used to declare functions that take an options object literal as their first arguments. @exportFunction is to regular functions as @exportClass is to constructors.
The usage of @exportFunction is as follows:
@exportFunction ol.control.defaults ol.control.DefaultsOptions ol.Collection
Note: the Function#export method uses a recursive function. This is to handle nested options.
Currently we have things like like in the generated externs file (types.js):
/**
* @type {ol.control.AttributionOptions|undefined}
*/
olx.control.DefaultsOptionsExtern.prototype.attributionOptions;
It doesn't make sense to have external object properties whose types are
internal (ol.control.AttributionOptions in the above example).
With this commit, the generate-exports.py script generates this:
/**
* @type {olx.control.AttributionOptionsExtern|undefined}
*/
olx.control.DefaultsOptionsExtern.prototype.attributionOptions;
When a style has no rules, the "else" symbolizers apply. When a style has rules and none of them apply to the given feature, the "else" symbolizers apply. Note that this is different than default symbolizer properties that might be merged into all symbolizers (as in OL2) - I don't think we should support that.