Proposal: URL/URI Helper Functions about jsonata HOT 8 CLOSED

@xogeny - I think the idea of a plugin system is a good one. Please could you raise a separate issue outlining your proposal (especially the external API)? Many thanks.

@jhorbulyk - I'm always open to adding more functions that are of genuine use to (at least) more than one user, and these might qualify on that. However, just because they are in the underlying Javascript language won't help the groups that are currently implementing JSONata in Java and Golang (plus any potential future implementors in other host languages). That is one of the reasons why this implementation has no dependencies on other packages.

from jsonata.

Can't you simply add these via assign/bindings/registerFunction?

from jsonata.

@xogeny You could register these functions however they encompase pretty standard functionality that one would want in most places which is why adding them to the set of built-in functions would be pretty desireable IMO.

from jsonata.

Do you think this could be addressed by having a plugin system for registering functions in bulk? That way, people could pick and choose what "libraries" of functions they wanted to have pre-defined in their application and it could even provide a mechanism to provide such libraries as packages in npm for easy use.

from jsonata.

A plugin system could be a useful JSONata feature. My thoughts:

• It isn't necessary for this particular request
• These exist as native functions in the underlying language (JavaScript). It seems sensible that they could also exist as native functions in JSONata.
• The cost of overhead of a plugin system may not be worth it given the relative symplicity of JSONata.
• JSONata appears useful as transformation language. I'm less certain about JSONata's utility as a framework for transformations.
• I can't think of use cases in which a user wouldn't want functions such as encodeURIComponent() to be available.

from jsonata.

All good comments. Regarding your last point, the issue is really just making sure the global namespace doesn't get too polluted. One could say "I can't think of a use cases in which a user wouldn't want ... mongodb/fetch/node/DOM/whatever ...functions to be available". But you make a good point that these are native to Javascript and don't introduce dependencies.

from jsonata.

Thinking about this more, I think there are two ways a "plugin" system could operate. It could either be used to add functions, in bulk, to an existing expression (essentially just invoking registerFunction on it many times). Or, it could modify the jsonata module itself (at runtime) to augment the default set of functions that get associated with every expression. Of course, one might choose to support both types. But I'd be curious if anybody has any feedback on what use case is more pressing...?

from jsonata.

Resolved by #357

from jsonata.