On 27.10.20 22:00, Winnebeck, Jason wrote:
Thanks Edmond for the feedback, and Alessio as well who replied also.
I know all of the expressions at once, although they can change as the
application runs, so it is possible to combine them into one class, but
I would then be constructing source code myself, which is a little bit
of a concern, and having to call methods dynamically via reflection
(rather than through an interface like I’d do if each one turned into a
Closure), which ups the complexity compared to SPEL.
actually if they all end up as Script, then you just have to call the
run method and put the values for the unbound variable in the binding.
No need for calling anything dynamic
The expressions may
also repeat, which is something I should consider (I know some of the
Groovy scripting utility classes will “cache” the code and handle this).
A map source->class/instance to bypass compilation, with a bit logic to
allow for garbage collection if memory is low or with an auto removal
after some time of not being used... memory sensitivity is a bit
difficult, but with an auto expunge things could be quite simple. If you
know the most common ones you could prepopulate the map even
[...]
I think the conclusion is that I should just test the performance to see
how it works out and how well it will scale over time. There is obvious
benefits in that Groovy allows “unlimited” potential compared to SPEL.
But “unlimited” could get us into trouble because I don’t want to be
making REST API calls and defining classes in an expression 😊, so do I
really need anything more than what SPEL gives to me. I know in Groovy I
do like the possibility to consider command chains that read better than
SPEL: “when vendor is ‘Apple’” -> when(vendor).is(‘Apple’)
that you could still do with templates in SPEL. No, for me SPEL has
reached absolutely its limit in expressiveness, when it comes to
requiring independent expressions. Of course you can easily say
vendor=='Apple'? 0.75 : 1
to express a discount of 25%, but if you do
vendor=='Apple'? 0.75 : vendor=='Samsung'? 0.8 : 1
it starts to turn into a problem imho. And with the third condition it
would be:
((count>=500 and count<=1000)? 0.9: 1) * (vendor=='Apple'? 0.75 :
vendor=='Samsung'? 0.8 : 1)
I am by far no SPEL expert, so this can surely get done much better...
but frankly conditions of this complexity are for me already more suited
to a language that also supports statements.
When I think about SPEL it actually should be efficient, too. I realize
template systems like Thymeleaf are based on this and evaluate many
expressions to render a single page. Likewise Groovy server pages /
Grails does it not do a similar thing? But maybe all of those closures
get mapped to a single class like JSP does.
the do
bye Jochen
