Add a Lexer/Parser for mathematical expressions. (Input Processor + Separate Action & Condition)

[fubhy]

Fixing implementation of the Shunting-yard algorithm.

[fubhy]

This is not yet finished. It is lacking test coverage and the usage of plain arrays for the output and for the stack in the Shunting-yard algorithm is going to be subject to change (I want to use \SqlQueue and \SqlStack there... Same for the initial tokenizing).

Note: This implementation seems to be extremely effective due to the compiled regex. I tried running a few (even complex) mathematical expressions and they correctly evaluated within a matter of microseconds. Yai

[fubhy]

Oh and it obviously lacks Drupal / Rules integration (still misses variable support, currently only handles constants). I also want to register the lexer and the parser as separate services. Not sure yet how I want to handle the registration of the default methods. Probably through a list of method calls in the services.yml.

[dasjo]

Add a docblock

[dawehner]

Can't you figure out the amount of arguments using reflection?

[fubhy]

I would like to avoid reflection due to performance concerns. Do you think it is viable to do this on runtime? Or are you saying that, once I move this to some other place, I would do this during the building of the container?

[dawehner]

Fair point. Yeah I kinda assumed that you cache that object

[fubhy]

Well, I will... Eventually (once I am registering as a service). So I will look at that again once that's done. That huge constructor with all the registering is going to go away in that process of course (that's just for now so I can work with it and test it).

[fago]

Makes sense. The variable should be number_of_arguments or so though, as it's not the actual function arguments.

[fubhy]

Once we retrieve that with reflection that argument would be gone anyways :P.

[fubhy]

I just made this a separate PHP library on GitHub: https://github.com/fubhy/math-php