ExoRule Syntax

[Jamie Thomas]

I am working on finalizing the ExoRule syntax for declaring rules, including the new PropertyGet-based rule invocation.  My problem with the prior syntax is you had multiple constructors to call and could easily pass parameters that did not make sense.  With the introduction of needing to specify return values separate from rule predicates, this gets even messier.  So I ended up with the following syntax (and variants) using a more fluent approach:

 

/// <summary>

/// Calculates the amount of fat represented by the current milk instance.

/// </summary>

static Rule CalculateMilkFat3 = new Rule<Store>(

       s =>

{

s.MilkFat = s.Milks.Sum(m => m.Fat);

       })

       .OnInit() // Init New & Init Existing

       .OnInitNew() // Init New

       .OnInitExisting() // Init Existing

       .OnChangeOf("Milks.Fat") // Property Change

       .Returns(s => s.MilkFat); // Property Get

 

 

This rule demonstrates a set of all potential fluent calls, although the three OnInit calls are redundant (you would call only one of these if desired).  Also, note the optional use of a declarative syntax for the Returns method that provides compile-time checking.  I am also considering something like this for OnChangeOf, but it is more difficult.

 

Also, Bobby recommended a few options for changing this syntax as follows:

 

/// <summary>

/// Calculates the amount of fat represented by the current milk instance.

/// </summary>

static Rule CalculateMilkFat3 = Rule<Store>

       .Perform(s =>

{

s.MilkFat = s.Milks.Sum(m => m.Fat);

       })

       .OnInit() // Init New & Init Existing

       .OnInitNew() // Init New

       .OnInitExisting() // Init Existing

       .OnChangeOf("Milks.Fat") // Property Change

       .OnAccessOf(s => s.MilkFat); // Property Get

 

I am not really sure the OnAccessOf name is accurate since it actual indicates that the rule sets these properties and may not run on access if the values are already assigned (aka, the rule intent is more about initialization than invocation triggering).  The Perform static method would be instead of calling the constructor to match the subsequent fluent syntax.  However, it kindof hides the delegate, so I am torn there too.

 

Anyways, please provide feedback on the above syntax and alternatives.  I will likely continue supporting the original constructor overloads as well for backwards compatibility, but make put together some search replace options for those that want to move exclusively to the new syntax.

 

Thanks,

Jamie