Why not change the complex way of data driven properties by allowing plain js functions?

[snuup]

Data driven properties in GeoJson (and maybe elsewhere?) is provided by types of ExpressionSpecification and alike. An expression tree system is implemented with appropriate typescript definitions:

	"line-opacity"?: DataDrivenPropertyValueSpecification<number>;
	"line-color"?: DataDrivenPropertyValueSpecification<ColorSpecification>;
	"line-translate"?: PropertyValueSpecification<[
		number,
		number
	]>;
	"line-translate-anchor"?: PropertyValueSpecification<"map" | "viewport">;
	"line-width"?: DataDrivenPropertyValueSpecification<number>;
	"line-gap-width"?: DataDrivenPropertyValueSpecification<number>;
	"line-offset"?: DataDrivenPropertyValueSpecification<number>;
	"line-blur"?: DataDrivenPropertyValueSpecification<number>;
	"line-dasharray"?: PropertyValueSpecification<Array<number>>;
	"line-pattern"?: DataDrivenPropertyValueSpecification<ResolvedImageSpecification>;
	"line-gradient"?: ExpressionSpecification;

I wonder why we do not simply allow functions as property values, that is the way js libraries usually handle this. Much less and much simpler code and a much simpler API for the user.

So instead of

map.addLayer({
    type: 'line',
    paint: {
        "line-width": 3,
        "line-color": ['get', 'color']
        // ???
    }
})

I suggest and prefer this api:

map.addLayer({
    type: 'line',
    paint: {
        "line-width": 3,
        "line-color": data => data.color,
        "line-width": data => (data.level * 2) ** 3
    }
})

[HarelM]

The spec is cross platform and serves native as well (c++), including java, objective-c and swift.
Introducing a parser to the json to support covering this expression into lambda in each language is a huge task (basically writing a compiler).
The spec is already very complicated to parse as it is now with the expressions, adding this extra layer would be hard to achieve and maintain...