Open peterdemartini opened 4 years ago
I like what you're going for here, but I'm hesitant to do anything that would expose executable code that neither Jexl nor the programmer explicitly supplied. One of the design goals of this library is absolute execution safety, in that an expression cannot execute any code outside of a tightly controlled sandbox. By exposing the native Object prototype, expressions gain access to a large library of tools that will change over time, and potentially be unsafe for certain applications. It also makes ports of Jexl to other languages nearly impossible to keep parity with the standard set by this library.
Providing a library of predefined transforms, though, is something I've been chewing on for some time, and would likely solve your use case. I'm not ready to take the leap there yet (it would be incredibly easy to make Jexl as large/heavy/complex as lodash practically overnight) but I'm definitely sensitive to any needs for it!
I think you have it backwards. This PR does not expose the toString
on the Object.prototype
, it allows a programmer to define a transformation named toString
since the current version of Jexl won’t allow it because it exists on Obect.prototype
.
@TomFrost ^^
@TomFrost I am sorry if I wasn't clear in original description but I'd definitely consider this a bug that is preventing us from creating using a transformer named toString
Hey @peterdemartini! I'm so sorry, I could have sworn I responded to your reply but I am clearly losing my mind in quarantine. This makes 100% sense and I apologize for my misunderstanding. I'm prepping a release for the near term (top-level functions support in expressions!) so I'll plan on getting this in for it as well!
No worries! Thanks for your help @TomFrost
For example, this allows specifying
foo|toString
orfoo|valueOf
. Previously this would error due to a syntax error.