More information sent to uc_price

(Writing down notes as we are talking about them here in Denver.)

In other words, carrying an array of alterers, including an operator and a delta, which can have additional alterers (elements in the array) to further add alterations to the price being passed in.

Find the alterers and do the alterations.

There needs to be an API function that gives that information to uc_price

class uc_price:

getAlterers()
resetAlterers()
getPrice(revision)

Use cases for example:

• Module writer just wants to display a price. (Has to be simple without knowing how the class works)
• Module writer wants to include tax and shipping for certain products and not others. (The actual information would have to make it into the context, as provided by tax, shipping, etc. This could be enabled and configurable by the admin.)
• We want to be able to apply the discount to the highest price product (likewise, a product "of equal or lesser value")
• Mutually exclusive discounts or offers, in other words "not valid with any other offer".
• Ability to allocate a discount to all the products - so discounts is not just a line item in the order, but it's an altered price applied to each product separately. This is useful if the product is returned or a refund is issued.
• We want to be able to display discount statistics at checkout. "You saved x amount" which we can't do if we're carrying around one number.
• Keeping track of price revisions in the database, so that accounting can know where the alterers came from and rebuild it if necessary. A history of the alterations.
• Does it allow re-rendering of alterers on a per-price basis as opposed to global?
• Enables shipping to (or from) multiple destinations such as drop shippers or multiple fulfillment centers.