Supporting extensions?

[alexsnaps]

Wonder how, if at all, this library would support extensions in ways the golang implementation does? We could have the need for the Strings(), how would that best be supported here, if that's interesting?

[clarkmcc]

It looks like these are just CEL functions that are namespaced and not available in the interpreter by default. The biggest missing piece in the library is the ability to namespace functions. You can already write your own functions and load them into the interpreter so I'm guessing your questions or more about (1) namespacing, and (2) whether we can provide these extensions out of the box.

I don't have any reservations about supporting this, though I do have several other features and PR reviews that are spec-compliance-related that I think are higher priority than this. That being said, if you wanted to take a stab at implementing, I'd be more than happy to review.

[alexsnaps]

Yeah :) I was thinking of providing this straight to this crate... Something along side how its done in Go

	env, err := cel.NewEnv(Strings())

Tho, unsure about the namespacing? Strings are straight methods on strings... are they not?

[alexsnaps]

Not so all of them, got it!

[alexsnaps]

I haven't dropped the ball on this... I ended up implementing this straight on our usage of this only because I didn't see how to best make this available from an API perspective in a way that's seamless enough quite yet. But in case it can be of any help to anyone, cel::strings on that PR has all initial string extensions.