Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JEP Syntax Policy #9

Open
innovate-invent opened this issue Feb 12, 2021 · 2 comments
Open

JEP Syntax Policy #9

innovate-invent opened this issue Feb 12, 2021 · 2 comments

Comments

@innovate-invent
Copy link

One of the qualities I enjoy of JMESPath is its syntactic simplicity.
I have seen a number of proposals to introduce new syntax for various purposes that has me concerned.
One example is adding a regex operator.
I would like to propose that operators and syntax be reserved for transforming, referencing, and subscripting data structures and not data values. All value specific operations should be implemented as functions. The exception to this would be arithmetic operators intended to operate on values.
This means all string operations other than those that could be reasonably described by an arithmetic operator should be implemented as a function.

Having complex value operations described as functions makes JMESPaths more readable.

@glenveegee
Copy link

a number of proposals to introduce new syntax for various purposes that has me concerned

Could you point them out as I'm interested where the proposals are. Might reveal the location where JEPs are actually being considered as it seems this repository has gone stale

@innovate-invent
Copy link
Author

The one that specifically motivated this issue was jmespath/jmespath.py#148 and #23
jmespath/jmespath.js#7 (comment) proposes both operator and function options.

This comment also proposes a new operator that I am on the fence on if it meets my criteria.

jmespath/jmespath.js#52 (comment) proposes new operators in line with what I am proposing, but another post suggests not even providing arithmetic operators. From a purist perspective they may have a point.

Ordering operators muddy my idea as it would be quite convenient to be able to sort or filter heterogeneous lists.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants