-
Notifications
You must be signed in to change notification settings - Fork 3
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-15 Third-Party Functions #5
Conversation
Gitter conversation discussing merit of this JEP and selection of proposed prefix: https://gitter.im/jmespath/chat?at=6219441ad1b64840db3cfb1c |
Thanks so much for writing this up. I have some notes about the final wording.
I think
This is an implementation detail that doesn't really need to be in language spec. It may be desirable for registration of conflicting functions to silently overwrite the conflict.
This is also an implementation detail. |
In theory 3rd party names MUST start with underscore. From then on, it followed that there must be some priority for built-in functions. Even for future ones. Another way of saying it is ; even though this change would not render your custom implementation non-compliant, you have no guarantee if ever a built-in function appears. What do you think? |
Agreed. But wanted to leave no room for ambiguity. |
I think we are saying the same thing. I'm trying to say that it can be silently ignored. But there should no circumstances for a built-in function to be overwritten by a custom implementation. Or are you specifically saying that the spec should not forbid that explicitly? |
My idea was to render all existing implementations non-complaint, with the follow up that most of the functions they currently provide would be added to the spec bringing them back into compliance.
I think that would be detrimental to backwards compatibility. |
I think that the language spec shouldn't speculate on implementation at all, otherwise it could cause implementer infighting on the various ways of interpreting the speculation. It is better to be ambiguous now and clarify later than to say something now and have to change it later. |
I see. Maybe we need to coordinate and list which functions we are talking about here.
Do you see others? |
I'm currently working on an app that is going to embed JMESPath with a bunch of custom functions so this is relevant to my interests. I was wondering how I could avoid my custom functions getting clobbered by a future version of the spec, which is how I ended up here :) Would you consider I think what would be really ideal is to have some sort of namespace for functions, so I could have something like |
@jordemort I'm secretly a fan of namespaces 😏 but we're not sure it's the best way to achieve this. Besides, we plan to include functions in the specification at a much faster pace than previously. Please head up to the discussions area to be involved. |
Closed in favor of corresponding discussion. |
Third-Party Functions
Abstract
This JEP proposes a new distinction between reserved function names
and _third-party function names. This allows the spec to evolve by
introducing new functions without the fear of clashing with existing
functions from popular third-party implementations.
Motivation
Virtually all the current language implementations of JMESPath support
registering additional "custom" functions that add features to JMESPath.
There is currently no restrictions as to what those function names may be
except that is must match the
unquoted-string
production.This proposal specifically acknowledges that third-party functions may
be used to extend JMESPath and mandates tha all third-party function
names should start with a leading underscore character.
Functions whose names starts with a letter – known or future – are
effectively reserved exclusively for use by JMESPath.
Specification
This JEP proposes adding the following text to the specification in the
Function Expressions section:
Rationale
This JEP does not introduce any grammar change.
Although there has been discussions about having a different semantic constructs
for both reserved functions and third-party functions, it has been considered
as an implementation detail. Besides, this would unnecessarily make it more
difficult for library authors to maintain two different logics for evaluating
functions.