Right now Jesse supports multiple Erlang representations of JSON object type: map() / proplist / {proplist()} / {struct, proplist()}.
It used to make sense before maps were introduced in OTP-17 in 2014. But now, over 7 years since then I think most of the libraries and systems are using maps for object representation. Jesse supports maps since 2016. Even jsx started to return maps by default since v3.0.
It should simplify the code quite a lot, because we would be able to use pattern-matching and is_map in guards, would be able to drop unwrap function usage, maybe even use maps:iterator() (OTP-21+) for the validator's "main loop".
We may provide some helper functions which would recursively convert legacy object representation to maps and back for those who are unable to migrate for some reason (by the cost of lower performance for such users). But I doubt that such legacy systems are going to bump the Jesse version anyway.
Maybe it would make sense to release a new tag with draft-06 support just before this change is implemneted, so those who can't update their JSON representation can still benefit from draft-06 implementation.
Right now Jesse supports multiple Erlang representations of JSON
objecttype:map()/proplist/{proplist()}/{struct, proplist()}.It used to make sense before maps were introduced in OTP-17 in 2014. But now, over 7 years since then I think most of the libraries and systems are using maps for object representation. Jesse supports maps since 2016. Even
jsxstarted to return maps by default since v3.0.It should simplify the code quite a lot, because we would be able to use pattern-matching and
is_mapin guards, would be able to dropunwrapfunction usage, maybe even usemaps:iterator()(OTP-21+) for the validator's "main loop".We may provide some helper functions which would recursively convert legacy object representation to maps and back for those who are unable to migrate for some reason (by the cost of lower performance for such users). But I doubt that such legacy systems are going to bump the Jesse version anyway.
Maybe it would make sense to release a new tag with draft-06 support just before this change is implemneted, so those who can't update their JSON representation can still benefit from draft-06 implementation.