Module
core
Description
Gracile filters currently only accept positional arguments via Vec<Value>. Tera and Jinja2 support named arguments: replace(from=".ts", to=""), which is self-documenting and avoids ambiguity for filters with multiple optional parameters.
Gracile requires replace(".ts", "") where the meaning of each positional argument must be memorized. For built-in filters with 1-2 args this is acceptable, but for user-defined filters with optional parameters (e.g., truncate(length=50, ellipsis="...") vs truncate(50)) positional-only args become ambiguous.
A possible approach would be to extend FilterFn to accept an optional HashMap<String, Value> of keyword arguments alongside the positional Vec<Value>, or to support a syntax like filter(key=value) that gets passed as named entries.
Module
core
Description
Gracile filters currently only accept positional arguments via
Vec<Value>. Tera and Jinja2 support named arguments:replace(from=".ts", to=""), which is self-documenting and avoids ambiguity for filters with multiple optional parameters.Gracile requires
replace(".ts", "")where the meaning of each positional argument must be memorized. For built-in filters with 1-2 args this is acceptable, but for user-defined filters with optional parameters (e.g.,truncate(length=50, ellipsis="...")vstruncate(50)) positional-only args become ambiguous.A possible approach would be to extend
FilterFnto accept an optionalHashMap<String, Value>of keyword arguments alongside the positionalVec<Value>, or to support a syntax likefilter(key=value)that gets passed as named entries.