So far, our custom expression language has only supported very simple variables-numbers and Boolean values. However, in real applications, this is often not so simple. When using an expression language to offer programmable business rules, you will often be working with structured data. For example, consider an e-commerce system in which a back-office user has the possibility to define under which conditions a discount should be offered to a user and what amount of a purchase should be discounted (the following figure shows a hypothetical example of how such a feature might actually look in an application).
Typically, you do not know beforehand how a user is going to use this feature. Using only numerical variables, you'd have to pass a whole set of variables when evaluating the expression, on the off chance that the user might be using one or two of them. Alternatively, you could pass an entire domain object (for example, a PHP object representing a shopping...