[jboss-jira] [JBoss JIRA] Closed: (JBRULES-47) Named Facts

[Mark Proctor (JIRA)]

     [ https://jira.jboss.org/jira/browse/JBRULES-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Proctor closed JBRULES-47.
-------------------------------

    Resolution: Out of Date


redundant now that we have bound inserts, via Commands.

> Named Facts
> -----------
>
>                 Key: JBRULES-47
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-47
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert)
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>
> There are times when you want to match facts by name, rather than by type+constraints. If we define a fact in an external process as
> Cheese stilton = new Cheese();
> stilton.setType("stilton");
> workingMemory.assertObject(stilton);
> The correct way to match this is object type match + field constraints:
> stilton:Cheese(type == "stilton")
> However there may be cases where you want to know that the bound variable stilton is bound to the same instance that the stilton variable references in the external application. This can be achieved via wrappers, similar to how primitive wrappers  work:
> Cheese stilton = new Cheese();
> stilton.setType("stilton");
> NamedFact stiltonNamedFact = new NamedFact("stilton", stilton);
> drools.assertObject(stiltonNamedFact);
> We can then have rules that do
> NamedFact( type=="org.cheesery.Cheese", type == "stilton", stilton:value )
> This first constraints the rule to the correct NamedFact and then binds the wrapped value to the stilton declaration. This can be further improved with syntactic sure to automate the boxing and unboxing of the fact
> drools.assertNamedObject("stilton", stilton);
> And in the rule we do
> rule "buy cheese"
>     var stilton;
>     when
>      .....
>     then
> end
> or maybe vars could be defined in a parameter fashion
> rule "buy cheese"(stilton)
>     when
>      .....
>     then
> end
> Caveat:
> This is generally a really bad idea and abused by people who still don't get the rule engine paradigm of pattern matching - and would use this though out their rule design. If you tie the matching process to named variables, extensively throughout,  the engine becomes "hamstrung" and cannot optimise, turning Drools into nothing more than a BSF like scripting framework - its like buying a Ferrari to go to the local shops and back. It's also a "code smell" in that it breaks the declarative rule logic encapsulation paradigm in that the filtering/matching is tied to an external procoss - coupling the processes together.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira