Creating Named and Dynamic Collections - Gnorion/BizVR GitHub Wiki
Creating Named and Dynamic Collections
Assume there are collections called PERSONS and DUCKS. We can now define some subsets of these collections:
HungryPersons = {p in PERSONS where p.hungry = true} // defines a collection of hungry persons
RoastDucks = {d in DUCKS where d.roasted = true and d.weight > 10} // defines a collection of roast ducks
NOTES:
- These two expressions are definitions
- They are not executed until HungryPersons or RoastDuck is referenced in a rule
- At that point membership of the collections is determined.
Then in a rule we might reference the collections of hungry persons and roast ducks:
{duck in RoastDucks, person in HungryPersons where duck.price < person.priceLimit}
This would match roast ducks with hungry persons that can afford them.
Dynamic Collections
We might also define a new collection called AffordableDucks
AffordableDucks = {duck in RoastDucks where duck.price < HungryPersons.priceLimit.max}
This AffordableDucks means the collection of roast ducks whose price is less than the maximum priceLimit of all the HungryPersons. Another way of looking at this is that this collection excludes any Duck whose price exceeds the highest value of pricelimit in the collection HungryPersons [Membership of the AffordableDuck collection will change dynamically as the wealthier members of HungryPersons get fed]
These collection names would then be usable in other rules (they would behave a bit like subclasses on the fly). The key is that the reference to HungryPerson would always be valid and would dynamically be updated (it may have to be a special data type - a dynamicCollection ) so that if a Person's weight increased to >100 or his appetite was satisfied during the execution of other rules they would no longer be a member of the HungryPersons collection (But they always remains a member of the PERSONS collection unless deleted).
This might also change the membership of the AffordableDuck collection to the same way that the action of a pattern matching rule can affect the instances that are bound - except that here the effect may propagate beyond the rule being executed..
The pattern matching rule now only deals with the join conditions since the collections HungryPersons and RoastDucks have taken care of the selections.
Basically what we have done here is allowed the definition of a bind variable to include the conditions for its selection.
We might go on to define the idea of suitable ducks;
SuitableDucks = {duck in AffordableDucks where duck.isTasty}
``